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Die folgenden Angaben sind den voni Anmelder eingereichten Unterlagen entnommen 

(§) Chipkarte und Verfahren zur Verwendung der Chipkarte 
® Chipkarte, die zur Durchfuhrung von Transaktionen 

dient, bei denen geldwerte Einheiten oder andere nicht- 

monetare Ansp ruche reprasentierende Wertdaten zwi- - 

schen dem Karteninhaber und mindestens einem Trans- 

aktionspartner (Service-Provider) ubertragen oder dem 

Service-Provider zur Verifizierung der Anspruche vorge- 

wiesen werden, wobei die Chipkarte einen Speicher urn- 

faSt r in dem zur Durchfuhrung der Transaktionen erfor- 

derliche Daten abgespeicherf werden, und die Chipkarte 

ferner folgendes aufweist: eine Einrichtung zum Laden 

von einer oder mehreren Kartenanwehdungen (VAS-App- 

likatiohen) auf die Karte, die jeweils die Durchfuhrung von 

Transaktionen zwischen dem Karteninhaber und einem 

oder mehreren Service-Providern ermoglichen. 
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Beschreibung 

Die Erfindung betrifrt eine Chipkarte, eiri Terminal zur Verwendung mil einer Chipkarte, ein Vferfahren zur Verwen- 
dung der Chipkarte sowie ein Chipkartensystem. 
5 Essind bereits Mikroprozessor-Chipkarten mit ZahlungsfunkUon, z. B. elektronische Geldborsen, ec-Cash Kredit- 
funkQon us^ im Einsatz und es sind je nach Auspragung durcb Organisationen, wie ZKA (Zentraler KreditausschuB) 
VISA Oder EMV (Europay Mastercard VISA), \forgaben festgelegt, so daB sie als Zahlungsmittel ("Geldersatz") ver- 
wendet werden konnen. Als beispielhafte Beschreibungen seien hier genannf 

10 - ZKA, Zentraler KreditausschuB, "Schmttstellenspezifikation fur die ec-Karte mit Ghip"i 27 10 1995' 

79^ XOP3y IntemalioDal * " Inte g rated Circuit Card, Specification for Payment Systems, EMV*96", V3.0, 30-Jun- 

- ISO/IEC 7816-4 "Information technology - Identification cards - Integrated circuit(s) cards with contacts Part 4- 
Interindustry commands for interchange", 01-09-1995; 

15 - prEN 1546-1 1 "Identification card systems - Inter-sector electronic purse, Part 1 : Definitions, concepts and struc- 

tures , 15.03.1995; 

03 0^995 546 ^' " IdentificatioD card sy**™ " Inter-sector electronic purse, Part 2: Security architecture", 

" P n rE ^ "Identification card systems - Inter-sector electronic purse, Part 3: Data elements and inferchan- 

20 ges , U9.12.1994. 

Ein aktueller Uberblick uber Chipkarten ist zu finden in: 

- Stefan Schutt, Bert Kohlgraf: "Chipkarten, Technische Merkmale, Normung, Einsatzgebiete" R Oldenboure 
25 Verlag, Munchen/Wien, 1996, ISBN 3-486-23738-1. noourg 

Herkommliche Chipkarten sind regelmaBig nur fur einen bestimmten Anwendungszweck, beispielsweise als elektro- 
nische Geldborse oder als elektronischer Ausweis, nutzbar. Die auf diesen Chipkarten aufgebrachten Anwendungen sind 
jedoch regelmaBig statisch, d. h. sie werden bei der Herstellung der Chipkarte aufgebracht und bleiben uber den Lebens- 
zyklus der Karte hmweg unverandert bestehen. 

Herkommliche Chipkarten sind also sowohl hinsichtlich ihrer Variabilitat als auch hinsichtlich ihrer Funktionalitat be- 
schrankt. Insbesondere sind herkommliche Chipkarten nach dem HerstellungsprozeB hinsichtlich ihrer Funktionalitat 
festgelegt und nicht mehr veranderbar. 

Es ist daher eine Aufgabe der vorliegenden Erfindung, eine Chipkarte zu schaffen,' deren Funktionalitat variabel ist 
Erne weitere Aufgabe der Erfindung besteht darin, eine Chipkarte zu schaffen, bei der die Zahl und Art der mit der 
Chipkarte durchftihrbaren Applikationen bzw. Anwendungen und Transaktionen auch nach dem HerstellungsprozeB 
noch vanabel isL Es soil mdglich sein, auf diese Chipkarte zusatzliche Applikationen "zu laden", es sollen Applikationen 
von .der Chipkarte geloscht werden konnen und die einzelnen Applikationen sollen daten- und sicherheitstechnisch un- 
abhangig voneinander definiert sein und unabhangig voneinahder ablaufen. 

Die Chipkarte soil beispielsweise die daten- und sicherheitstechnischen Voraussetzungen nach ISO 7816 erfullen* die 
einzelnen Apphkationen der Karte sollen jedoch insbesondere von der Kartenplattform selbst unabhangig sein 

Es ist eine weitere Aufgabe der Erfindung, eine Chipkarte zu schaffen, bei der der Benutzer die Anzahl und Art der in 
seiner Karte verfugbaren Applikationen selbst bestimmen bzw. zusammenstellen und andern kann. 

Es ist femer eine Aufgabe der vorliegenden Erfindung, eine Chipkarte zu schaffen, mit der sowohl Intraservices (d h 
45 geschlossene Applikationen in dem Sinne, daB keine Abrechnung und Leistungsubertragung mit extemen Partnern zu er- 
folgen hat) als auch Interservices (d. h. Apphkationen mit zusatzlichen AuBenbeziehungen zu externen Partnern) ermoc- 
hcht und durchgefuhrt werden konnen. 

GemaB einem Aspekt der Erfindung ist eine Einrichtung vorgesehen, mit der eine oder mehrere Kartenanwendungen 
auf die Karte geladen werden konnen, mit denen jeweils die Diirchfuhrung von Transaktionen zwischen dem Kartenin- 
50 haber und einem oder mehreren Service-Providem ermoglicht wird. 

Durch das Laden wird die Chipkarte so konfiguriert, daB sie eine neue Funktionalitat erhalt, d. h. eine Applikation aus- 
fiihren kann, die lhr bisher nicht moglich war. Durch die geladenen Daten werden Applikationen definiert und in Verbin- 
dung mit den Grundfunktionalitaten der Karte wie etwa dem Betriebssystem realisiert, die vorher nicht auf der Karte vor- 
handen waren. Damit wird die Funktionalitat der Karte durch das Laden einer Applikation urn eben diese Applikation er- 
55 weitert. . 

GemaB einem Ausfuhrungsbeispiel der Erfindung ist auf der erfindungsgemaBen Chipkarte eine Datenstruktur 
(DFJVAS) vorgesehen, die selbst wiederum in eine Teilstruktur und einen Definitionsdatensatz unterteilt ist, wobei die 
I>atenstruktur mittels einer sie identifizierenden Kennung eindeutig identifiziert ist und somit von der Kartenplattform an * 
sich unabhangig ist. In die Teilstruktur konnen nun sogenannte Applikationen geladen werden, d.h. Funktionalitaten 

60 oder Anwendungen der Chipkarte. Damit wird es durch Laden einer bestimmten Applikation der Chipkarte moglich, 
Transaktionen zwischen dem Karteninhaber und einem fur diese Applikation spezifischen Service- Provider durchzufuh- 
ren. Ein Definitionsdatensatz innerhalb der Datenstruktur enthait Informationen uber die Art und/oder die Struktur der in 
der Teilstruktur geladenen Applikationen. Zumindesf der Definitionsdatensatz, vorzugsweise jedoch die gesamte Daten- 
struktur sind mittels mindestens eines Systemschlussels gegen Modifikatiohen abgesichert und nur unter \ferwendung 

65 dieses Schliissels modifizierbar. Anstelle eines Systemschlussels sind auch andere Sicherungsmechanismen oder Siche- 
rungseinrichtungen vorsteUbar, mittels derer die Absicherung gegen Modifikationen erfolgen kann, etwa durch eine per- 
sonUche Kennziffer (PIN) oder sonstige zur Absicherung dienende Einrichtungen. 

Mit der obigen Struktur ist es moglich, in die Teilstruktur verschiedene Apphkationen zu laden und diese auch wieder 



30 



35 



.40 



2 



DE 197 18 115 A 1 

aus der Teilstruktur zu loschen, so daB die Karte hinsichtlich ihrer Funktionalitaten bzw. der mit ihr durchfiihrbaren An- 
wendungen vanabei isL Laden und Loschen von Applikalionen geschieht durch Schreiben von applikationsspezifischen 
Daten und Schlusseln in die vorhandene Teilstruktur. Durch Vorsehen des Systemschlussels und der Datenstrukturken- 
nung wird die die Multifunktionabtat ermoglichende Datenstruktur unabhangig von der Kartenpiattform an sich und 
auch hinsichtlich ihrer Sicherheitsarchitektur selbsttragend und unabhangig von der Kartenpiattform. 5 

Abhangig von den in der Teilstruktur geladenen Applikationen konnen dann mittels der Karte Transaktionen zwischen 
dem Karteninhaber und Service-Providern, die von den geladenen Applikationen abhangig sind, durchgefuhrt werden 
Vorzugsweise weist die Chipkarte femer einen Transfer-Speicherbereich auf, in den die bei der Durchfuhrung von 
Transaktionen auszutauschenden Daten geschrieben bzw. aus dem sie gelesen werden. Indem fur das Entnehmen von 
Daten aus dem Transfer-Speicherbereich terminalspezifische Schlussel vorgesehen werden, sind die einzelnen Zugriffe 10 
sicherheitstechnisch voneinander unabhangig. " 

Die einzelnen in der Karte vorhandenen Teilstrukturen bzw. Applikationen sind vorzugsweise voneinander unabhan- 
gig und jeweils einem bestimmten Service-Provider zugeordneL Sie stellen sozusagen die fur diesen Service-Provider 
proprietaren oder spezifischen Daten zum Durchfuhren einer bestimmten Applikation dar. Sie enthalten deshalb je nach 
Applikationstyp und je nach Service-Provider unterschiedliche Informationen, beispielsweise Daten, die einen bestimm- is 
ten Wert reprasentieren (Bonuspunkte, Kontostand, etc.), Informationsdaten iiber die Apphkation, Informationsdaten 
iiber den Service-Provider, etc. Vorzugsweise enthalten sie jedoch insbesondere auch fur die Applikation spezifische 
Schlussel, mittels derer ein ZugrifT auf die Daten der Teilstruktur auf sicherheitstechnisch von anderen Teilstrukturen un- 
abhangige Art und Weise ermoglicht wird. Das Laden oder Generieren der Teilstruktur bzw. Applikation selbst ist dage- 
gen mit zumindest einem ubergeordneten Systemschlussel abgesichert ° 2 o 

Vorzugsweise findet vor dem Durchfuhren einer Transaktion eine gegenseitige Authentifizierung zwischen Chipkarte 
und einem Terminal statt, wobei dabei ein applikations- bzw. teilstrukturspezifischer Authentifizierungsschlussel vorge- 
sehen ist. 

Zum Durchfuhren von Transaktionen werden dann Daten in eine fur die jeweilige VAS-Applikation reservierte Teil- 
struktur geschrieben oder daraus gelesen oder iiber den Transfer-Speicherbereich abgewickelt. Im ersten Fall werden 25 
applikationsspezirische Schlussel verwehdet. Im letzteren Fall wird ein applikationsspezifischer und vorzugsweise auch 
ein terminalspezifischer Schlussel, der beispielsweise mittels eines Schlussel-Erzeugungsschliissels, der auf der Karte 
vorgesehen ist und aus applikauonsspezifischen Daten generiert wird, verwendet. Die so in den Transferspeicher ge- 
schriebenen Daten konnen dann vom Service-Provider iiber das Terminal entnommen werden, was vorzugsweise durch 
Kennzeichnen der im TVansferspeicher gespeicherten Daten als entwertet geschieht. Handelt es sich dabei urn einen Ser- 30 
vice-Provider, der nicht fur die schreibende Applikation spezifisch ist, so wird dadurch ein sogenannter Interservice aus- 
gefuhrt, d. h. es werden zurri Nutzen bzw. auf Kosten des Karteninhabers geldwerte Daten zwischen unterschiedlichen 
Service-Providern ausgetauscht 

Als zusatzliche Sicherung ist ferner eine PIN oder ein PaBwort zur Verifikation der Berechtigung eines Transaktions- 
vorgangs vorgesehen. 35 

Durch die variable Struktur der Karte konnen zu verschiedenen Zeitpunkten verschiedene Applikationen in unter- 
schiedlicher Anzahl auf der Karte untergebracht sein. 

Die Echtheit von aus dem Transfer-Speicher entnoramenen Daten wird vorzugsweise unter Verwendung eines Siguier- 
schliissels bzw. unter Verwendung einer digitalen Unterschrift oder mindestens eines Schlussels gesichert. Besonders 
vorteilhaft ist es dabei, wenn die entnommenen Daten weiter im Transfer-Speicher verbleiben, jedoch lediglich durch die 40 
Karte als entnommen gekennzeichnet werden. Dadurch konnen auch nach der Transaktion noch Informationen uber die 
durchgefuhrte Transaktion erhalten werden. Damit und mit der Absicherung der Entnahme ist auch Einmaligkeit nach- 
weisbar. 

. Besoncjers vorteilhaft ist es ferner, wenn die in den Transfer-Speicher geschriebenen Daten mit einem Verfallsdatum ■ 
gekennzeichnet sind, nach dem sie ihren Wert veriieren. Dadurch werden Applikationen realisierbar, die beispielsweise 45 
die Bereitstellung eines fur einen bestimmten Zeitraum gultigen Tickets ermoguchen. 

Mittels eines Vorzugsweise vorgesehenen Transakuonszahlers konnen die TVansaktionsdateh bzw. die Wertdaten hin- 
sichtlich ihrer zugehorigen Transaktion eindeutig bestimmtund identifiziert werden. 

Die erfindungsgemaBe Chipkarte besteht in einer vorteilhaften Ausftihrungsform also aus einem hierarchischen Spei- 
cherkonzept, das auf seinen unterschiedlichen Ebenen mittels verschiedener SchlUssel gegen Modifikationen abgesichert 50 
ist, das auf der Ebene der Applikationen hinsichtlich der in den Speicher geladenen Applikationen variabel ist, wobei 
jede einzelne Applikation durch eigene spezifische Schlussel gegenuber anderen abgesichert und von diesen unabhangig 
ist, und wobei die Gesamtstruktur mittels mindestens eines Systemschlussels und mittels einer die Struktur identifizie- 
renden Kennung gesichert und von der Kartenpiattform selbst unabhangig ist.' Das Konzept des Transferspeichers er- 
moglicht den Austausch von Daten sowohl zwischen Karteninhaber und Service-Provider als auch zwischen unter- 55 
schiedlichen Service-Providern selbst Auch das Lesen und Schreiben in den bzw. aus dem Transferspeicher ist durch 
Schliissel abgesichert, wobei diese ebenfalls karten- und appplikationsspezifisch, zusatzlich jedoch auch noch terminal- 
'- spezifisch sind. Eine Authentifizierung, die vor jeder Transaktion durchgefuhrt wird, sowie optional eine PIN oder ein 
PaBwort erhohen zusatzlich die Sicherheit der erfindungsgemaBen Chipkarte. 

In den Patentanspruchen 21 bis 30 wird ein Terminal zur Verwendung mit der erfindungsgemaBen Chipkarte definiert. 60 
Dieses Terminal dient zum Laden oder Loschen von Applikationen, zur Durchfuhrung von Transaktionen, zum Ansehen 
von Daten sowie zur Durchfuhrung von weiteren in Verbindung mit den jeweiligen Applikationen und Transaktionen 
stehenden Funktionen. Ein Verfahren zum Durchfuhren von Transaktionen zwischen Karteninhaber und Service-Provi- 
der ist in den Anspriichen 31 bis 33 definiert, das Laden von Daten auf eine erfindungsgemaBe Chipkarte definieren An- 
spriiche 34 und 35, und Anspruch 36 definiert ein Gesamtsystem aus Chipkarte und Terminal. 65 

Nachfolgend wird die vorliegende Erfindung anhand eines bevorzugten Ausfuhrungsbeispiels naher beschrieben, wo- 
bei Bezug auf die beiliegenden Zeichnungen genommen wird. Dabei zeigen 

Fig. 1 schematisch die erfindungsgemaBe Chipkarte, 
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Fig. 2 eine schematische Darstellung des Gesamtsystems der Komponenten der Erfindung, 
Fig. 3 den DatenfluB im Gesamtsystem, 

Fig. 4 die moghchen Appukationsklassen und Operationen durch ein Transaktionsmodell in schematischer Darstel- 
lung, 

Fig. 5 eine schematische Darsteilung der Sicherheitsarchitektur der erfindungsgemaBen Chipkarte, 
Fig. 6 die Dateistruktur einer allgemeinen Implemenuerungsklasse des VAS-Containers, 

Fig 7 verschiedene Implementierungsklassen des VAS-Containers gemaB einem Ausruhrungsbeispiel der vorlieeen- 
den Erfindung, 

Fig. 8 die Dateistruktur des VAS-Containers gemaB einem Ausfuhrungsbeispiel der vorliegenden Erfindung 
Fig. 9 schematisch die Dateistruktur der Implementierungsklasse DF_PT, ° ' 

Fig. 1 0 schematisch die Dateistruktur der Implementierungsklasse DF_AD. 

?,! o° r ^ e Erfindun S niher teschrieben wird, soUen einige, im nachfolgenden verwendeten Begriffe definiert werden- 
VAS: Value Added Services 

x, Y^-Karte: Die VA S-Karte ist eine Chipkarte, mit der an den Value Added Services teilgenommen werden kann Die 
VAS-Karte enthalt neben anderen Anwendungen wie z.B. Zahlungsappbkationen (also elektronische Geidborse) den 
VAS- Container. ' 

VAS-Container: Der VAS-Container beinhaltet Datenstrukturen, Zugriffsbedingungen, Schliissel und (Erganzungs-) 
Kommandos zum Verwalten von VAS-Applikationen und der BereitsteUung der Funktionalitat der VAS-Apphkationen 
VAS-Applikation: VAS-AppUkationen enthalten VAS-Daten. Zugriff auf die VAS-Daten wind durch die VAS-Appli- 
™?° ' g^teuert. Em VAS-Provider betreibt im VAS-Container eine oder mehrere VAS-Applikationen. Die Nutzung der 
VAS-Applikation defimert sich aus dem Aufbringen, Lesen und Verarbeiten von VAS-Daten. Eine VAS-Applikation 
kann entweder als Intra- oder Interservice ausgepragt sein. 

VAS-Provider: Der VAS-Provider ist fur seine VAS-Applikation yerantwortlich, die er nach Rahmenbedingungen des 
System Operators und nach semen eigenen Vbrstellungen entwickelt und danach uber den System Operator und die Ter- 
minals den Cardholders zur Verwendung bereitstellL Die VAS-Applikationen sind in den VAS-Container der VAS-Karte 
zu laden, bevor daran teilgenommen werden kann. 

Intraservice: Intraservice ist eine Sorte von VAS-Appukation, die unter exklusiver Regie des jeweiligen VAS-Provi- 
ders benutzt wird. Intraservice Applikationen sind geschlossene Appukationen in dem Sinne, daB keine Abrechnunc 
oder Leistungsubertragung mit extemen Partnern erfoigt Eine VAS-Applikation kann entweder als Intra- oder Interser- 
30 vice ausgepragt sein. 

Interservices: Interservice Applikationen sind Intraservice Applikationen, die uber zusatzliche AuBenbeziehungen zu 
externen Partnem unterhalten. Eine VAS-Applikation kann entweder als Intra- oder Interservice ausgepragt sein 

, S ? r \ S JT m °P eraton Der S y stem Operator, oder System Betreiber, bietet den VAS-Providern und den Cardholders 
das VAS -System zur Nutzung an. 

Issuer: Der Issuer, oder Kartenherausgeber, bringt die VAS-Karten mit VAS-Container in den Umlauf. 
CH, Cardholder: Der Cardholder, oder Karteninhaber, ist die Person, die die Karte (hien VAS-Karte) besitzt und ein- 
setzt, urn an den Value Added Services teilzunehmen. Diese Person ist nicht zwangslaufig der eigentliche Eigentiimer der 
ivarte. w 

Serviceterminal: Das Servic^terminal wird vom System Operator fur VAS-Applikationen aufgestellt. Am Serviceter- 
minal kann der Karteninhaber die VAS-Applikationen auf seiner VAS-Karte verwalten (Laden, Ansehen, Loschen und 
Ubertragen von VAS-AppUkationen). 

Handlerterminal: Das Handlerterminal besitzt Zah'lungsfunktionen und bietet zusatzlich VAS-Funktionalitat An ihm 
setzt der Karteninhaber seine VAS-Karte ein, um einerseits zu bezahlen und gleichzeitig an den \brteilen von VAS teil- - 

znnp.hmpn 
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zunehmen. 

AID: (Application Identifier) maximal 16 Byte langer Name von Applikationen zur eindeutigen Unterscheidung von 
Applikationen und der Applikationsselektipn von auBen ohne Kenntnis der Dateistruktur einer Karte. Die AID besteht 
aus einer 5 Byte langen Registered Application Provider ID (RID) und optional aus einer maximal 11 Byte laneen Pro- 
prietary Application Identifier Registration (PIX). 
DF: Directory File. nach ISO 7816 
50 EF: Elementary File nach ISO 7816 

Gultiger VAS-Container: VAS-Container, der sich gegenuber der externen Welt authentisieren kann. 
KID: (Key Identifier) Nummer eines Schlussels innerhalb eines Elementary Files, das Schliissel enthalt 
R&R: Rules and Regulations 

p: Maximale Zahl von Objekten der Implementierungsklasse DF_PT 
55 a: Maximale Zahl von Objekten der Implementierungsklasse DF_AD 

nr D1R : Maximale Gesamtzahl von Objekten: nr DIR = p + a. Die Anzahl von Records in EF_DIR ist nr DIR . 
°^ef_trans fer" Anzahl von Records des EF_TRANSFER. 

Fig. 1 zeigt schematisch die Struktur der erfindungsgemaBen Chipkarte. Zusatzlich zu den statisch und nicht verander- 
baren, beim HerstellungsprozeB aufgebrachten Daten wie dem Masterfile MF und der (optional vorhandenen) Geldbor- 
60 senfunktion DF_Borse ist auf der erfindungsgemaBen Karte noch ein Verzeichnis bzw. eine Datenstruktur oder Datei- 
struktur DF_VAS vorgesehen. Diese dient zur Aufhahme von Zusatzfunktionalitaten, sogenannten Value Added Services 
VAS. Aufgrund dieser ZusatzfunktionaUtateh, die Applikationen darstellen, die auch noch zu einem spateren Zeitpunkt, 
also nach der Herstellung der Karte, auf die Karte geladen werden konnen, ist die Karte hirisichtlich ihrer Funktionalita- 
ten und der mit ihr durchfuhrbaren Transaktionen flexibel und variabel. Der auf der erfindungsgemaBen .Chipkarte vor- 
gesehene sogenannte VAS-Container (DF_VAS) ermoglicht die Variabilitat und HexibUitat der Chipkarte bezuglich ih- 
rer Funktionen und lost daneben die auf der Chipkarte untergebrachten Appbkationen sicherheitstechnisch von der Kar- 
tenplattform, so daB diese von der Kartenplattform unabhangig sind und eventueli sogar auf eine andere Karte ubertragen 
werden konnen. 
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Die erfindungsgemafien, neuen Zusaizfunkuonalitaten (Value Added Services. VAS) werden realisiert durch Mikro- 
prozessor-Chipkarten. Die Umsetzung dieser Zusatzfunktionabtalen wird duxch den VAS-Container realisiert. Der VAS- 
Container auf der Mikroprozessor-Chipkarte bildet die Plattform zur Aufnahme der VAS-Applikationen. Die VAS-App- 
likationen sind die jeweiligen Realisierungen besiimmter Zusaizfunkuonalitaten. 

Ini Fall der elektronischen Geldborse wird das Bezahlen mit der Karte (Zahlungsfunkuon) und die Nutzung einer 5 
VAS-Applikation (Zusatzfunktionabtat) uber getrennte Mechanismen abgewickelt; aus Sicht des Kartennutzers bzw. 
Karteninhabers kann dies aber als ein Vorgang erscheinen. 

Die Mikroprozessor-Chipkarte wird erweitert urn den VAS-Container, der verschiedene und unabhangige Applikauo- 
nen aufnehmen kann. Er stelll Funktionen zum Aufbringen, Loschen und Ubertragen dieser Applikationen zur Verfu- 
gung; diese konnen nur vom autorisierten Systembetreiber verwendet werden. Der VAS-Container ist daten- und sicher- 10 
heitstechnisch unabhangig von anderen Systemkomponenten auf dem Mikroprozessor-Chip. Der VAS-Container ist 
vollstandig durch sich selbst definiert und allein funktionsfahig. Fiir inn ist eine unabhangige Sicberheitsarchitektur de- 
finiert, so daB VAS-Applikationen eigenstandige Sicherheitsfunknonen verwenden. Die Sicherheitsarchitektur verwen- 
det kartenspezifische Schlussel, die nicht hersteUerspezifisch und die unabhangig von Identifikationsrnerkmalen der Kar- 
tenplattforni sind. . !5 

Der VAS-Container verwendet auch Mechanismen zur Ableitung terminalspezifischer Schlussel. Mit dies en kann der 
VAS-Container selbst aktiv die Echtheit von Terminals bzw. die von ihnen erzeugten Daten priifen. 

Im VAS-Container werden die VAS-Applikationen abgelegt, die uber Mechanismen des VAS-Container Daten bereit- 
stellen und dadurch die Steuerung der zugeordneten Schnittstelleri bewerkstelligen. Der VAS-Container ermogucht und 
steuert auch den sicheren Austausch von Daten fur Interservices zwischen Partnern. Der VAS-Container erledigt aktiv 20 
die Kontroile, d. h. die Echtheit und die Einmaligkeit, der ubertragenen Datenwerte. 

Ein Vorteil des VAS-Container gegenuber anderen Ansatzen von Multi-Applikations-Karten ist, daB dieses Konzept 
unabhangig von einer bestimmten Kartenplattform ist. Es bietet eine Sicherheitsarchitektur, die unabhangig von piatt- 
formspezifischen Sicherheits mechanismen (wie Schlussel, Identifizierungsdateri, PIN, Signaturverfahren) ist. 

Ein weiterer Vorteil des Konzeptes VAS-Container ist, daB die Anzahl der verschiedenen Applikationen auf der Karte 25 
nicht fest vorgegeben ist durch Beschrankungen und Vorgaben zum Zeitpunkt der Kartenherstellung oder der Kartenaus- 
gabe; die aktuelle Kartenbelegung mit Anwendungen ist frei wahlbar durch den Kartennutzer und ist nur durch den auf 
der jeweiligen Karte zur Verfugung stehenden Speicherplatz beschrankL Die Anzahl der aktuell auf einer Karte gelade- 
nen VAS-Applikationen hangt vom tatsacWichen Gebrauch der Karte ab. Der. Kartennutzer stellt individuell die VAS- 
Applikationen auf seiner Karte zusammen; dies beinhaltet auch die Anderung der Zusammenstellung zu einem spateren 30 
Zeitpunkt. Der VAS-Container ermoglicht eine multifunktionale Karte, bei der die Kartenfunktionalitat wahrend des Le- 
benszyklus der Karte variabel in Anzahl und Art der Anwendungen zusammengestellt und verwendet werden kann. Es 
konnen so auch Anwendungen, fur die bislang einzelne, spezielle Karten notwendig waren, auf nur einer Karte abgelegt 
werden und zum Einsatz kommen. VAS-Applikationen konnen auch auf andere Karten ubertragen werden. Damit kon- 
nen VAS-Applikationen den Lebenszyklus einer Karte uberleben; sie begleiten den Kartennutzer wahrend des Lebens- 35 
zyklus der Anwendungen. 

Die Mikroprozessor-Chipkarte mit Zusatzdiensten ist ein geeignetes Medium zur Verbreitung und zur Vermarktung 
von Dienstleistungen, bei denen auf geschutzte Daten zugegriffen werden muB. Diese Mikroprozessor-Chipkarte kann 
als Zahlungsmittel, Recheneinheit und zur Wertaufbewahrung verwendet werden: Sie kann entsprechend dem Kunden- 
wunsch vom Kunden selbst und nach Kartenausgabe flexibel mit Zusatzdiensten versehen und zu deren Steuerung her- 40 
angezogen werden. Sie kontrolliert auch aktiv die Authentizitat von beteiligten Tbrminals und stellt die Einmaligkeit und 
Echtheit von ubergebenen Daten sicher. 

Fig. 2 zeigt eine Systemubersicht. Darin dargestellt sind die Systemkomponenten. 

Ein Systembetreiber (System Operator) stellt das System zur Verfugung. An Serviceterminals (ST) kdnnen VAS-App- 
likationen geladen, geloscht und ubertragen werden; weitere Operationen sind: VAS-Applikation aiiswahlen, ansehen, 45 
interpretieren usw. * 

Die Anbieter von VAS-Applikationen, die sogenannten VAS-Provider, entwerfen eigene VAS-Applikationen nach den 
Rahmenbedingungen des Systembetreibers und, soweit moglich, nach eigenen Vorstellungen. Durch AbschluB mit einer 
digitalen Unterschrift werden die entsprechenden Terminalprogramme auf Echtheit nachpriifbar. 

Fig. 3 zeigt den DatenfluB im System. " 50 

Die VAS%Applikationen werden uber den Systembetreiber an den Tbrminals den Kartennutzern zur Verwendung be- 
reitgesteUt. VAS-Applikationen sind in den VAS-Container der erfindungsgemafien Chipkarte zu laden, bevor daran teil- 
genommen werden kann. 

An Handlerterminals (HT) wegen auf der Karte vorhandene VAS-Applikationen genutzt, indem VAS-Daten aufge- 
bracht bzw. geloscht werden. 55 

Zur Realisierung der Mikroprozessor-Chipkarte mit VAS-Funktionalitat wird neben anderen bestehenden Anwendun- 
gen (z. B . Zahlungsapplikationen wie die elektronische Geldborse) der VAS-Container auf der Karte aufgebracht 

Der VAS-Container verwendet Funktionen, die ein Aufbringen, Loschen und Obertragen von VAS-Applikationen er- 
moglichen. Diese Verwaltungsfunktionen werden ausschlieBlich vom System Operator benutzt und sind in der Karte ge- 
gen Fremdbenutzung abgesichert. Der VAS-Container beinhaltet einen Transferspeicher, mit dem der Austausch von Da- 60 
ten zwischen VAS-Appbkationen realisiert wird. 

Zur Steuerung des Transferspeichers werden zwei Kommandos TRANSFER und TAKE eingesetzt. Das Kommando 
TRANSFER erzeugt eirien Eintrag im Transferspeicher mit fur die jeweilige Applikation spezifischen Daten. Neben den 
Nutzdaten zahlen hierzu auch die.zur Steuerung der Verarbeitung notwendigen Angaben wie Datum, Verfallsdatum und 
Identifikationsdaten. Mit dem Kommando TAKE werden Objekte aus dem Transferspeicher entnommen und als entnom- . 65 
men markiert, Je nach Anwendungsfall werden die Objekte dann als weiterhin giiltig oder als ungiiltig markiert. Uber- 
tragene Daten werden durch den VAS-Container auf Echtheit und Einmaligkeit uberpriift. 

VAS-Applikationen verwenden zur Bereitstellung und Steuerung der Anwendungen VAS-Daten. Zugriff auf die VAS- 
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Daten wird durch die VAS-Applikation gesteuert, die sich dazu Mechanismen bedient, welche im VAS C™t ,11 
Apphkauonen bereitgestellt sind. Ein VAS-Provider bedeibt im VAS-Container^rirmeh^l VA< ^ t ?. n ? aUen 

Der VAS-Container unterstulzt Interservices. Interservices erfordeni Zueriff auf eemeinsame n atm 
5 Le-stungsanspruchen und die Abrechnung von Leistungen zwischen verscwSS KST VOn 
BeSiSlf auf^^wSef erfindU W maBen ^ipkarte moglichen Dienste bzw. Applikationen anhand von 

IHeBeschreibung beaeht sich jeweils auf die Erscheinungsweise und Funktion nach dem Stand der Technik Die 
Funktion soli zukunfbg durcb eine oder mehrere VAS-Applikationen nachgebildet werden ° ,e 
10 Als erstes werden Intraservices vorgestellL 

Beispiel A: Kundenclub 

Ein Kaufhaus betreibt einen Kundenclub. Der Kunde wird in diesero Club Mitelied und erhalt mit diesem <0. a r,,c c~. 
IS Z ,fische Qubleistungen die Nichtmitglieder nicht erhaken konnen. Heute identiEs^ 

umgebung durch e.nen Clubausweis. Der Clubausweis wird beim Eintritt erstellt, ist nicht ubert™ w fnrf w h » 
gel eine Gultigkeitsdaue, Ober den Clubausweis werden keine n»ia^SS£SiSSSS^^ J£| 

sasESST Damit 8renzt der Clubausweis VOD Bonu Spro g~ ab d ; £ sT£ 

20 Analog: GroBhandler Ausweis, Senator Card, Buchclub. 

Ziel: Die Clubzugehorigkeit soli durch eine Applikation im VAS-Container nachgewiesen werden. 

Beispiel B: Bonussystem 

25 Ein Kunde erhalt fur jede TVansaktiori einen Bonusanspruch vergutet. Der Bonusanspruch wird kumuliert u „rf L a „„„ 

S^^^£S3^ anonym Oder personenbezogen verwaltet wcden. Der Bonusanspruch 2fi 
Analog: Punktestand von Miles & More. 

Ziel: Das Punktekonto soli durch eine Applikation im VAS-Container verwaltet werden. 

Beispiel C: Rabatt 

Der Kunde erhalt Volumenrabatt nach Plan. Der Rabatt wird fiir jede einzelne Transaktion gewahrt Die Karte verwal 
tet keine Umsatzhistorie. Jede Transaktion ist in sich abgeschlossen gewanrt. uie Xarte verwal- 

Ziel: Der Rabattanspruch soil durch eine VAS-Applikation ausgewiesen werden. 

Beispiel D: Ausweisfunktion 

Eine Person kann ^urch Merkrnale in der Karte gegeniiber Dritten nach weisen, daB Berechtigung zu bestimmten Lei- 
stungen besteht Die ^gehorigkeit der Person zum Ausweis muB bei jeder Transition nzchgJte!w*ri^SiMd 
PIN, Biometnk). Die Echtheit des Ausweises wird als Sicherheitsmerkmal herangezogen (Lichtbild, 

Analog: Internet Zugang, Zugang Homebanking, Telefonkarte. . 
. Ziel: Die Berechtigung soil durch eine VAS-Applikation nachgewiesen werden. 

Beispiel E: Werteinheiten 

H J^ nh6iten ^ fden T™*? " nd durch ein " meh ^alige Nutzung verbraucht. Pro Transaktion verringert sich 
so Nntz^g ™* Nutz ^ sb -^tigung ist Ubertragbar und kann EinschrankuSen^ Ke . 

^Analog: Einzelfahrschein, Streifenfahrschein, Abo-Konzertkarte, Squash-Zehnerkarte, Kino-Ticket, Telefoneinhei- 

Ziel: Durch eine VAS-Applikation soli die Abwickiung rauonalisiert werden. 

Beispiel F: Nutzungsabrechnung 

a nc^ e , NU ?; U K g u eiDe f Leistu 1 n i wir ? T nach ^ Haufigkeit oder Menge registriert und nach Tarifplan abgerechnet Im vor- 
aus 1st nicht bekannt, in welchem Umfang die Leistung abgerufen wird. S^ecnnei. im vor 

Analog: Verzehrbon, Kurzzeitparkschein. 

^Ziel: Durch eine VAS-AppUkation soil, die Abrechnung nach Tarif ermoglicht werden. Die jeweils aktuell benotigten 
Abrechnungsdaten soUen im VAS-Container gespeichert sein. " ucnougien 

Beispiel G: Merkzettel (Mobiler Datenspeicher) 

Diese Applikation ermoglicht die Obergabe von Daten des Karteninhabers an den VAS-Provider. Dadurch werden Ab- 
iLTntT 8 £u derzeit noch manuell erfolgen. Aus diesen Daten laBt sich kein geldwerter Gegenwert ableiten. 
Analog: Ausfullen von Lottoscheinen, Emkaufszettel, Kassenzettel, Telefonregister. 

Ziel: Em VAS-Provider soil die Daten der Karte entnehmen und so den entsprechenden Dienst direkt erbringen konnen 
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(z. B. Telefonverbindung herstellen, gewunschte Waren zusammensteilen, elektroniscb den Lottoschein ausfuUen und 
erfassen). Die Daten konnen sowohl kurzfristig als auch langfristig in der Karte gespeichert werden. 
Nach diesen Beispielen fur Intraservices sollen nun einige Beispiele fur Interservices folgen. 

Ein Interservice entstebt immer dann, wenn an einem Dienst mehrere VAS-Provider beteihgt sind. Dies ist untrennbar 
damit verbunden, daB Daten den Bereich eines VAS-Provider veriassen. Heute geschieht dies uber Bescheinigungen auf 5 
Papier. 

Beispiel A: Fahrpreiserstattung 

Ein Kaufhaus erstattet einem Kunden den Fahrschein eines OPNV-Unternehmens fur die Fahrt zum Kaufhaus. Der to 
Kunde mu8 dem Kaufhaus den Emzelfahrschein vorlegen. Das Kaufhaus vermerkt auf dem Fahrschein, daB er erstattet 
wurde. Eventuell bekommt das Kaufhaus seinerseits einen Teil der Erstattung an den Kunden vom \ferkehrsunternehmen 
zuriick. 

Ziel: Der Erstattungsvorgang soil elektronisch abgewickelt werden. 

Beispiel B: Fahrgutschein 

Ein Kaufhaus erstattet dem Kunden beim Warenkauf die Kosten fur eine Heimfahrt, indem ein Gutschein ausgestellt 
wird. Der Kunde erhalt an einem Fahrkartensch alter ein Ticket des OPNV bzw. zahlt einen geringeren Preis fur das Tik- 
ket. Der Verkehrsbetrieb rechnet den Gutschein mit dem Kaufhaus ab. 

Ziel: Abbildung der Mechanismen durch VAS-Applikationen mit elektronischer Abrechnung zwischen Handel und 
OPNV. 

Beispiel C: Kundenparkplatz 

Ein Kaufhaus erstattet dem Kunden einen Teil der Parkgebuhren bei Benutzung eines bestimmten Parkhauses. Das 
Parkhaus wird durch ein unabhangiges Unternehmen betrieben und erhalt vom Kaufhaus eine geldwerte Vergutung fiir 
jede Kundengutschrift. 

Ziel: Abbildung der Mechanismen durch VAS-Applikationen mit elektronischer Abrechnung zwischen Handel und 
Parkhaus. 
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Beispiel D:.Multilaterales Bonusprogramm 

Eine Gruppe von Handelsuntemehmen und Dienstleistem einigt sich auf ein gemeinsames Bonusprogramm. 
Ziel: Jeder Partner kann Bonuspunkte auf einem gemeinsamen Konto auf der Karte gutschreiben oder vergiiten. Die 
Abrechnung der Leistungen zwischen den Partnern erfolgt durch das Hintergrundsystem. 

Beispiel E: Anerkennung von Bonuspunkten zwischen Dienstleistem 

Jeder Dienstleister betreibt ein eigenes Bonusprogramm, hat aber Absprachen mit anderen, gesammelte Punkte anzu- 40 
erkennen. Bekannte Beispiele sind Absprachen zwischen Autovermietern und Fluggesellschaften zum Sammeln von 
"Meilen". 

Ziel: Unterstutzung der Ubertragung von Bonuspunkten durch die Karte. 

Jeder VAS-Provider soli zunachst seine Punkte fur sich sammeln, ohne daB ein anderer eingreifen kann. Fur die Ober- 
tragung sollen sichere Mechanismen bereitgestellt werden. 45 

Beispiel F: Nachttaxi 

Durch einen Fahrausweis des OPNV wird gleichzeitig die Berechtigung zur Fahrt im Sammeltaxi (z. B. nach 22.00 
Uhr) erworben. Das Taxiunternehmen muB zur Abrechnung nachweisen, daB der Fahrausweis vorgelegen hat. Die Inan- 50 
spruchnahme des Taxis wird auf der Karte vermerkt, um MiBbrauch zu unterbinden. 

Ziel: Die VAS-Applikation soil die Inanspruchnahme, Kontroile und Verrechnung dieses Dienstes ermoglichen. 

Im folgenden soil der Aufbau der erfindungsgemaBen Chipkarte naher beschrieben werden. 

Die Mikroprozessor-Chipkarte mit VAS-Funktionalitat enthalt insbesondere den VAS-Container. 

Der VAS-Container ist eine eigenstahdige Anwendung und existiert entweder alleine oder auch parallel neben anderen 55 
Applikationen auf der zugrundeliegenden Kartenplattform. Der VAS-Container ist vollstandig durch sich selbst definiert 
und allein funktionsfahig. Er kann ohne die in der Regel auf der gleichen Karte yorhandene Zahlungsfunktion betrieben 
werden. Insbesondere wird fur den VAS-Container eine unabhangige Sicherheitsarchitektur definiert, so daB VAS-App- 
likationen eigenstandige Sicherheitsfunktionen verwenden konnen. 

Teil der Value Added Services sind Transaktionen durch den Kunden, die an Terminals der VAS-Provider durchge- 60 
fuhrt werden. Der. VAS-Provider hat ein Interesse, diese Transaktionen zu verfolgen, sei es zum Zweck der Systemuber- 
wachung oder sei es zur Sammlung von statistischen und anderen Daten. Zur Optimierung und Vereinheitlichung der Da- 
tenstrukturen in der Karte wird von der Verwendung applikationsspezifischer Identifikationen abgeraten und die Nutzung 
einer systemweit eindeutigen VAS-Container ID empfohlen. Diese Nummer kann vom VAS-Provider zur Realisierung 
der o.g. Funktionen benutzt' werden, und sie befreit ihn von der Burde, eigene Nummemkreise zu verwalten. 65 

Die Sicherheitsarchitektur des VAS-Containers verwendet diese systemweit eindeutige ID zur Ableitung kartenspezi- 
fischer Schliissel. Die Verwendung der kartenspezifischen Nummer ware im Prinzip moglich, wird aber vorzugsweise 
nicht verwendet, da, falls der VAS-Container auf unterschiedlichen Plattformen implemenu'ert wird, diese unter Umstan- 
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den kollidierende Nummernkreise verwenden. 

Die VAS-Container ED wird vorn System Operator vergeben und durch den Kartenissuer bei der Erzeueune des VAS- 
^° n w. n o^ e,ngebraCht - SiC ^ dem L6SGhen des ^-Containers vemichtet und damit aus dem System entfemt. 
Ein VAS-Container gilt als geldscht, wenn er keine VAS-Applikationen enthalt und die VAS-Container ID entfernt ist 
5 Bei emer Oesamtubertragung des VAS-Containers von einer alten in eine neue Karte wird die VAS-Container ID zu- 
sammen nut den VAS-AppUkationen transferiert, Dieser Transfer entspricht einem Versehieben des VAS-Containers aus 
der alten in die neue Karte. Die alte Karte enthalt nach diesem Vorgang keinen VAS-Container mehr. Der in der neuen 
Karte vorhandene VAS-Container wird bei dieser Operation uberschrieben und damit geloscht Da die VAS-Container ID 
von der alten auf die neue Karte iibertragen wird, ist in den Hintergrundsystemen der VAS-Provider keine Umwandlune 
10 der Bezugsnummem erforderlich. 6 
Einzelne VAS-Applikationen konnen nur unter der KontroUe des jeweiligen VAS-Providers zwischen zwei verschie- 
denen VAS-Containem verschoben werden. Bei dieser Funktioh andert sich die Zuordnung zwischen VAS-Container ID 
und VAS-Applikation, was u. U. im Hintergrundsystem des VAS-Providers vermerkt werden muB 

Der VAS-Container enthalt keine personenbezogenen Merkmale. VAS-Applikationen konnen personenbezogene Da- 
is ten entnalten, der Umfang sollte jedoch aus Datenschutzgriinden und zur besseren Speicherausnutzung auf ein Minimum 
beschrankt werden. VAS-Applikationen soUen, falls erforderlich, personenbezogene Daten im Hintergrundsystem spei- 
chern und die Zuordnung zur Karte uber die VAS-Container ID herstellen. 

Ein wesendiches Merkmal des VAS-Containers ist die Unterstutzung von Interservices. Interservices erfordern Zugriff 
auf gemeinsame Daten, Ubertragung von Leistungsanspriichen und die Abrechnung von Leistungen zwischen verschie- 
20 denen Partnern. Der VAS-Container muB dieses ermoglichen und trotzdem die Sicherheit der Applikationen im Intraser- 
vice gewiihrleisten. rr 

Sogenannte Intraservice VAS-Applikationen sind Applikationen, die unter der exklusiven KontroUe des VAS-Provi- 
ders betrieben werden. Der VAS-Provider definiert die Sicherheit seiner Applikation unabhangig von einer externen 
btelle. Ohne Weitergabe der Schlussel kann keine externe Partei VAS-Daten verandem. 

Zur effizienten Abwicklung von Interservices miissen die Partner auf gemeinsame Daten zugreifen konnen Der ce- 
meinsame Zugnff auf die Daten ist uber abgestufte Sicherheitsmechanismen realisiert. " 

Die erste Stufe des gemeinsamen Zugriffs erfolgt ausschbeBlich uber offentliche Transferfelder. VAS-Provider konnen 
uber diese Feider Daten austauschen, ohne gegenseitig die Applikationen und Schlussel kennen zu mUssen Lediglich 
zum Schreiben von Daten in die TYansferfelder mussen die Terminals uber geeighete Schlussel verfugen, nicht aber zum 
Lesen. Lesen darf jeder ohne Emschrankung. Der Datenaustausch kann in beiden Richtungen zwischen VAS-Provider 
und Partner erfolgen, wenn jeder iiber seinen Schlussel zum -Schreiben verfugt. Die Transferdaten konnen aus einer In- 
traservice VAS-Appukation des VAS-Provider erzeugt werden oder umgekehrt kann der VAS-Provider Daten aus dem 
Transferfeld in seine Intraservice VAS-Applikation hereinnehmen. 

Die zweite Stufe ist das Entwerten von Werteinheiten, die durch VAS-Daten verkorpert werden Ein VAS-Provider 
bnngt Werteinheiten in die VAS-Daten mit einem speziellen Schlussel zum Schreiben ein. Die Werteinheiten konnen 
durch Interservice Parmer abgenutzt werden, die iiber einen Schlussel zum Entwerten verfugen, den sie vom gesamtver- 
antworUichen VAS-Provider bekommen. In dieser Stufe greifen Partner mit unterschiedlichen Rechten auf nicht-offent- 
hche VAS-Daten zu. 

Die dritte Stufe ist der direkte schreibende Zugriff auf die VAS-Daten durch alle beteiligten Interservice Partner. Diese 
Methode erfordert eiri entsprechendes MaB an Vertrauen zwischen den Parteien, da uneingeschrankt VAS-Daten veran- 
dert werden konnen. 

Das Transferfeld dient als Koppelglied zwischen VAS-Applikationen. Daten im Transferfeld werden von den VAS- 
Apphkationen im VAS-Container erzeugt. Daten konnen auch direkt im Transferfeld angelegt werden, wenn der Erzeu- 
. ger keine eigene VAS-Applikation im VAS-Container betreibt. 
45 Das Transferfeld steht prinzipiell alien Applikationen zur Verfiigung, schreiben darf* aber nur wer iiber eine Berechti- 
gung (Schlussel) dafur verfugt. Nur nach den Regeln, d. h. den Rules und Regulations R&R, dazu berechtigte Empfanger 
durfen Daten aus dem Transferfeld entnehmen. Der Empfanger pruft das Vorhandensein von fur ihn bestimmten Trans- 
ferdaten und enmimmt sie zur Verarbeitung im eigenen System. 

Urn die Manipulation von Transferdaten im offendichen Austausch zu verhindern, bringt der Erzeuger ein Echtheits- 
50 merkmal und der VAS-Container eine Sequenznummer ein. Mit diesen Elementen wird die Einmaligkeit einer Transfer- 
. nachricht sichergestellt und der Ursprung der Daten nachgewiesen. 

Bei Bedarf wird der Empfanger der Transferdaten vom Erzeuger mit der Mdglichkeit ausgeriistet, eine Echtheitspru- 
. fung durchzufiihren. Wird dies riicht gewiinscht, kann die Akzeptanz der Daten auch nach Treu und Glauben erfolgen* 
das Echtheitsmerkmal wird dann u. U. erst bei einer Abrechnung im Hintergrundsystem des erzeugenden VAS-Provider 
55 gepruft. 

Die Daten konnen aus dem Transferfeld nur einmalig mit Erhalt eines Echtheitsmerkmals enUiommen werden. Bei der 
Entnahme werden die Daten markiert und verbleiben (als Kopie) im Transferfeld. Damit kann auch nach der Entnahme- 
der Daten fiir einen bestimmten Zeitraum der TYansfervorgang nachgewiesen werden. 

Daten im Transferfeld tragen eiri Verfallsdatum. VerfaUene Daten konnen bei Bedarf von beliebigen Applikationen 
60 uberschrieben werden. Die Daten im Transferfeld konnen bei der Entnahme markiert werden, so daB sie zum sofortigen 
Uberschreiben freigegeben sind. Sollte sich der Transferspeicher dennoch vollstandig fullen, bevor ein Transferdatensatz 
verfallt, so muB der Karteninhaber am Serviceterminal nicht mehr benotigte Eintrage loschen. 

Fiir die ModeUierung von VAS-Applikationen werden 3 Operadonen definiert. Diese Operationen wirken auf die 
VAS-Daten. Laden und Loschen von Applikationen sind Funktionen des VAS-Containers und werden hvden folgenden 
65 Absatzen nicht betrachtet 

Erwerben Allgemein das Erwerben eines Leistungsanspruchs und die Ablage eines Nachweises in den VAS-Daten ei- 
ner VAS-Applikation. 

Entwerten Allgemein das Einlosen des Anspruchs ohne, mit vollstandigem oder mit teilweisem \ferbrauch von VAS- 
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Daten einer Applikation. Der Vorgang erzeugt eine elektronische Quittung, die im Transferfeld abgelegt wird. Diese 
Quittung tragi ein sinnvolles Verfallsdaium, zu dem sie aus dem Transferspeicher geloscht werden kann. 

Entnehmen AUgemein die Entnahme der elektronischen Quittung aus einem Transferfeld zur weiteren Verarbeitung 
(z. B. Hintergrundsystem). Eine Kopie der Quittung verbleibt und dient als Nachweis des "Entwertens". 

"Erwerben" von VAS-Daten kann nuf durch den jeweiligen VAS-Provider erfolgen. "Entwerten" von VAS-Daten kann 
nur durch den VAS-Provider erfolgen, der sie mil "Erwerben" erzeugte oder durch einen Interservice Partner, den der 
VAS-Provider dazu ermachtigt "Entnehmen" kann auch durch jeden anderen VAS-Provider erfolgen. Bei einem Inter- 
service ohne gleichberechtigten Zugriff auf die VAS-Daten lost der Partner den Zustandsubergang "Entnehmen" aus. Die 
so gewonnene elektronische Quittung kann dann uber den System Operator und das Hintergrundsystem des VAS-Provi- 
der abgerechnet werden. "Erwerben" und "Entwerten" kann in einem Schritt erfolgen. 

VAS-Applikationen mil gemeinsamen Merkmalen lassen sich in Klassen unterteilen. Diese Klassen bilden die Basis 
fur Datenstrukturen im VAS-Container: Der VAS-Provider wahlt bei der Implementation seiner Anwendung eine Appli- 
kationsklasse aus. 

Es werden dabei folgende Applikationsklassen definiert: 

- Punktespeicher 

- Ticket 
-Ausweis 

- Gutschein 

- Datenspeicher. 

Punktespeicher bezeichnet eine Applikationsklasse, in der ein Konto von Punktwerten verwaltet wird. Auf das Punk- 
tekonto konnen Werte aufgebucht und abgezogen werden. Das Aufsuchen von Werten erfolgt durch den VAS-Provider, 
indem der Speicher mit dem neuen Kontostand beschrieben wird. Das Abbuchen von ^ferten erfolgt durch die "Entwer- 
ten"-Operation, wobei als Beleg eine elektronische Quittung im Transferspeicher abgelegt wird. Der Zugriff auf die bei- 
den Funktionen ist durch zwei unterschiedliche Zugriffsschlussel realisiert 

Ticket bezeichnet eine Applikationsklasse, in der ein Wertfeld existiert, welches einmalig oder mehrmalig entwertet 
und damit verbraucht wird. Das Aufbuchen von Werten in der Applikationsklasse Ticket erfolgt einmalig. 

Ausweis bezeichnet eine Applikationsklasse, bei der die VAS-Daten den Nachweis einer Berechtigung beinhalten. 
Der Nachweis wird in, der Regel nicht durch Nutzung verbraucht; er wird allerdings nach einem definierteh Kriterium, 
z. B. nach zeitlichem Verfall, ungultig. Je nach Auspragung der Applikation wird die Echtheit des Ausweises (z. B. An- 
wohnerparkschein) oder die Vorlage eines Ausweises dokumentiert (z, B. Sammeltaxifahrt mit Monatsfahrschein: Er- 
zeugen einer elektronischen Quittung durch die Karte. Die Quittung wird vom Taxiunternehmen beim OPNV eingereicht 
und anteilig verrechnet). Optional kann die Nutzung des Ausweises durch elektronische Quittungen im Transferspeicher 
der Karte dokumentiert werden .- 

Gutschein bezeichnet eine Applikationsklasse, bei der Leistungsanspriiche (in der Regel kurzfristig) in der Karte zwi- 
schengespeichert werden. Diese elektronischen Gutscheine werden ausschlieBlich im Transferspeicher des VAS -Contai- 
ners gespeichert Die den Gutschein verwertende Applikation ist in der Regel eine andere als die erzeugende Anwen- 
dung. Die Entnahme des Gutscheins aus dem Transferspeicher ist nur einmalig moglich und wird durch die Karte doku- ' 
mentiertl Ein vom VAS-Container erzeugtes Echtheitsmerkmal kann bei der Abrechnung im Hintergrundsystem benutzt 
werden. 

Datenspeicher bezeichnet eine Applikationsklasse, bei der ein VAS-Provider Daten im VAS-Container speichert, die 
fur den Kiinden einen zusatzlichen Service bieten (z. B. Letztes Menii in Fast-Food Restaurant, Letzte Lottozahlen, Ser- 
vice Praferenzen, Vorschlagslisten). Die Daten sind nur zur Information und stellen keinen Leistungsanspruch gegen den 
VAS-Provider dar. Der Zugriff auf die Daten wird vom VAS-Provider gesteuert. 

Jede Applikationsklasse zeichnet sich durch einen typischen Nutzungszyklus aus. Die folgende Tabelle zeigt, in wel- 
cher Frequenz diedrei oben definierten Operationen auf die VAS-Daten der Applikationsklasse angewendet werden (Zur 
Beachtung: "Erwerben" bedeutet nicht "Applikation laden" und r, Entnehmen , ' bedeutet nicht "Applikation ldschen"). 
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Tabelle 1 
Nutzungszyklus 





Punkte- 
speicher 


Ticket 


Ausweis 


Gutschein 


Daten- 
speicher 


Erwerben 


Mehrfach 


Einfach 


Einfach 


Einfach 


Mehrfach *** 


Entwerten 


Mehrfach 


Mehrfach 


Mehrfach 


Einfach 


Nie 


Entnehmen 


Mehrfach 


Mehrfach 


Mehrfach 


Einfach 


Nie 
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15 



20 



25 



*** In der Applikationsklasse n Datenspeicher" wird nicht ein Anspruch erworben, 
sondem die Applikation trSgt lediglich Daten in die Applikation ein. 

Fig 4 veranschaulicht die oben aufgefuhrten Applikationsklassen und Operationen durch ein Transaktionsmodell 
Im folgenden soU auf die Sicherheitsarchitektur der erfindungsgemaBen Chipkarte naher eingegangen werden Zur 
Gewahrleistung der Sicherheit werden die folgenden Schlussel definiert: 

TabeUe 2 

Schlusselubersicbt 



30 



35 



40 



45 



50 



Name 


Ort 


Inhaber 


Beschreibung 


K so 


VAS- 
Contairier 


System 
Operator 


SchjOssel fur Verwaltung des VAS- 
Containers 


Kaut 


VAS- 
Container 


System 
Operator 


Schlussel fQr Authentifizierung des VAS- 
Containers 


KsiG VASQ 


VAS-^ 
Container 


System 
Operator 


Schlussel zum Signieren der 
Transaktionsdaten 


KGK DEC 


VAS- 
Container 


System 
Operator 


Schlussel fur die Ableitung des 
KGKnpn Pty 




VAS- 

Applikation 


VAS-Provider 


Schlussel fur den Schreibzugriff auf VAS- 
Daten 


KrvaSP 


VAS- 

Applikation 


VAS-Provider 


SchlQssel fur den Lesezugriff auf VAS- 
Daten 


KGK DECPIX 


VAS- 
Provider 


VAS-Provider 


Schlussel fur die Ableitung des K DEC 




Handler- 
terminal 


VAS-Provider 


SchlQssel fQr Authentifizierung des 
Handler-terminals 



55 



60 



65 



Die Sicherheitsarchitektur basiert auf dem Lebenszyklus von VAS-Container bzw. VAS-Applikationen und ist nach 
^y erantwortlichkeit de ^ beteiligten Instanzen geschichtet. Eine erlauterende schematische DarsteUung ist in Fig. 5 ge- 

Nachfolgend einige Erlauterungen zur Struktur des VAS-Containers sowie der darauf aufgebrachten AppUkationen 
Der VAS-Container sowie VAS-spezifische Erganzungskoinmandos werden entweder vom Issuer zusammen mit an- 
deren Nicht- VAS-Applikationen auf die Karte gebracht oder spatestens an einem Serviceterminal durch einen autorisier- 
ten VAS-Provider auf einer bestehenden Kartenplattform integriert. 

Fur die zweite Moghchkeit kann der folgende Mechanismus Verwendung finden: Der System Operator verabredet mit 
dem Issuer einen temporaren Schlussel K so *. Der Issuer offnet die Karte mit seinem nur ihm bekannten Schlussel legt 
die Dateien des VAS-Container an und schreibt insbesondere den K so * in das DF^VAS. Der System Operator kann dann 
zu einem spateren Zeitpunkt (z. B. die Karte kommt zum ersten Mai mit einem Serviceterminal in Beruhrung) den 
Schlussel K so * durch seinen eigenen Schlussel K so ersetzen, den dann nur er alleine kennt Der System Operator kann 
nun weitere Daten, wie z. B. den KGK DEC , selbst eintragen oder im Falle einer Plattform mit dynamischer Speicherver- 
waltung Dateien fur VAS-Applikationen selbst erzeugen bzw. loschen. Damit ist sichergestellt, daB der Issuer nach der 
ersten Benutzung einer VAS-Karte keinen Zugriff mehr auf den VAS-Container hat und der System Operator lediglich 
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Zugriff sauf den VAS-Container. Da es mit anderen Applikationen keine gemeinsamen Datenstrukturen und keinerlei 
Datenaustausch gibt, ist die Sicherfaeitsarchitektur des VAS-Containers somit unabhangig von anderen auf der Karten- 
plattform vorhandenen Applikationen. 

In einer speziellen Ausfuhrungsform der Erfindung soil jedoch von der ersten Moglichkeit Gebrauch gemacht werden- 
Der Issuer soli im Auftrag des System Operator den VAS-Container inklusive aller Schlussel auf die VAS-Karten auf- 
bringen. 

Der VAS-Container besteht aus einer vorgegebenen Dateistruktur, vorgegebenen Zugriffsbedingungen (ACs) und ei- 
nigen globalen Daten. Die globalen Daten enthalten u. a. den Schlussel K so zum Laden bzw. Loschen von VAS- Appli- 
kationen. Uber diesen Schlussel, den nur der System Operator kennt, wird sichergestellt, daB nur zugelassene VAS- App- 
likationen geladen werden konnen. Die Karte verlangt dazu eine externe Authentifizierung des System Operators mit 
K so . 

Wenn ein Karteninhaber an einem Serviceterminal eine VAS-Applikation laden mdchte, beauftragt der zustandige 
VAS-Provider den System Operator damit, dies fur ihn zu tun. Beim Laden der VAS-Applikation in den VAS-Container 
ubergibt der VAS-Provider dem System Operator die Schlussel K^^p und K RVASP die dieser mit in die Applikation 
eintragL Durch den Schlussel K^^p kann der VAS-Provider Daten der Applikation vor schreibendem Zugriff und zu- 
satzlich interne Daten vor lesendem Zugriff schutzen. Dazu verlangt die Karte eine externe Authentifizierung des VAS- 
Provider basierend auf K^^p; d. h. die Karte priift aktiv die Echtheit des Terminals. Nach erfolgreicher Ausfuhrung 
dieser Funktion wird einem Terminal der schreibende Zugriff auf eine VAS-Applikation und der lesende Zugriff auf in- 
terne VAS-Daten der Applikation erlaubt. Eine interne Authentifizierung, d. h. die Priifung der VAS-Applikation (und 
damit der Karte) auf Echtheit durch das Handlerterminal, kann optional erfolgen. Bei der Nutzung der VAS-Applikation 
durch den Karteninhaber konnen an beliebigen Terminals, die uber den Schlussel Klvasp verfugen, diese intemen VAS- 
Daten in die Applikation geschrieben bzw. verandert werden. Die Funktion "Erwerben*' stiitzt sich deshalb auf einen UP- 
DATE RECORD Befehl, dem eine externe Authentifizierung mit dem Schlussel K^^p vorausgehen mu8. 

Der. lesende Zugriff auf alle nicht intemen Daten der VAS-Applikation ist nur erlaubt, wenn eine vorberige exteme 
Authentifizierung durch K RVAS ^> oder durch Kgo oder durch die korrekte Eingabe einer PIN oder eines PaBwortes durch 
den System Operator erfolgt Der PIN-/PaBwort-geschutzte Zugriff wird vorgesehen, urn Daten fur den Karteninhaber an 
Terminals oder am Wallet einsehbar zu machen. Der Karteninhaber hat an einem Serviceterminal die WahL, fur alle App- 
likationen gieichzeitig einen PIN-/PaBwort-Schutz fur das Lesen der Wert- bzw. Statusdaten zu aktivieren bzw. zu deak- 
tivieren. 

Zu den globalen Daten des VAS-Container gehort ein Schlussel K^q VASC zum Signieren von entnommenen Daten 
aus dem Transferfeld. Anhand der Signatur kann die Unversehrtheit dieser Transaktionsdaten nachgepruft werden, wenn 
sie manipulationsgesichert zwischen Interservice Partnern zur gegenseitigen Verrechnung iibertragen werden mussen. 
Zusatzlich zu einer optional durch die Interservice Partner eingebrachten. Signatur wird fur Datensatze, die die Karte mit 
der Operation "Entnehmen" ausgibt, eine Signatur basierend auf K SIG V asc und einem vom VAS-Container verwalteten 
Transaktionszahler hinzugefugL Da zwar Lesen des Transferfeldes jedem erlaubt ist, jedoch die Signatur der Karte mit 
k stg_vasc nur beim Aufruf der Operation "Entnehmen" erzeugt wird (und dies kann nur einmalig geschehen), wird die 
unzulassige doppelte Abrechnung von Gutscheinen erkannt. Jeder Interservice Partner kann sich vom System Operator 
die Echtheit und Einmaligkelt eines entnommenen Gutscheins bestatigen lassen. AuBerdem kann vom System Operator 
durch Priifung der Signatur die Echtheit des VAS-Containers nachgewiesen werden. 

Soilte eine Kartenplattform asymmetrische Schlusselverfahren unterstiitzen, kann als K SIG VASC auch ein privater 
(geheimer) Schlussel innerhalb der Karte zum Signieren herangezogen oder ein solcher Schlussel aus einem privaten 
Key Generating Key abgeleitet werden. Die VAS-Provider konnten in diesem Fall offentliche (nicht geheime) Schlussel 
zur eigenen Priifung der Signatur heranziehen, ohne den System Operator konsultieren zu mussen. 

Zu den Daten des VAS-Container gehort ein globaler Key Generating Key KGKdec, der fur alle Terminals aller VAS- 
Provider zur Berechtigungspriifung der Operation "Entwerten" den Zugriffsschliissel Kp^ erzeugen kann (mehr zur 
Schlusselableitung und Priifung folgt spater). An das Entwerten von geldwerten Daten werden nicht die gleichen Sicher- 
heitsmaBstabe wie an das Laden bzw. Erwerben eines Anspruchs gestellt. Es geniigt hier, anstelle eines applikationsei- 
genen Schlussels einen globalen Schlussel zu verwenden. Dieser globale Schlussel wird durch Ableitung zunachst in ei- 
nen ApplikationsschlUssel uberfuhrt und anschheBend durch emeutes Ableiten zum TerminalschlusseL Dem VAS-Pro- 
vider wird nur die applikationsspezifische Ableitung des globalen Schlussels zur Erstellung eigener Terminalschlussel 
ubermittelt. Dies wird nachfolgend kurz geschildert: 

Wir bezeichnen mit mac(k,d) die Berechnung eines Message Authentication Code fur eine Nachricht d und einen DES- 
Schlussel k mittels DES. Falls die Nachricht nicht langer als 8 Bytes ist, entspricht dies der Verschlusselung selbst 
(ICV=0 vorausgesetzt). Wir bezeichnen mit macp(k,d) die Berechnung von mac(k,.d) mit anschlieBender Angleichung 
der Paritatsbits. Das Ergebnis k' = macp(k,d) ist wieder ein giiltiger DES-SchliisseL 

Die Berechnung des applikationsspezifischen Terminalschliissels geschieht dann wie folgt: 

. 1 . Jede Karte speichert einen Schlussel 

der fur alle Karten gleich ist und der das Geheimnis des System Operators ist. Der System Operator veranlaBt, daB 
dieser Schlussel in die Karte personalisiert wird. 

Aus diesem Schlussel konnen samtliche VAS-Applikations- und Terminalschlussel abgeleitet werden. 
2. Ein VAS-Provider mochte eine VAS-Applikation A mit AID A =RID VAS • PDC A einfuhren. Nun feerechnet der Sy- 
stem Operator aus dem Schlussel KGK DEC und der PIX den applikationsspezifischen Schlussel 
KGK DEC Prx = macp(KGK DEC , PDC A ) 
und ubergibt diesen Schlussel dem VAS-Provider. 
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3. Di<*er VAS-Provider leitet aus KGK DBCPIX ftir alle Terminals, die das TRANSFER- Kommando auf die VAS 
Appkkation Aanwenden sollen, nut Hilfe ihrer Terminal ID ihre spezifischen Schlussel ab- 
tS^I^^Z GKd ^^ x ' Terminal ID) = macpOnacpOCGKoec PK A ), Terminal ID). 

, u^_V° . , P e,chert diese Schlussel in seinen Terminals. Sofem der VAS-Provider nicht selbst die Termi 
nalsbetobt, genenert er die Schlussel und verteiltsie an die Betreiber der Terminals ' 

wLrtm^S^ ? T ^ FE * Kommand ° ™ durch. wenn das Kommando ein vom Terminal erzeugtes 

Kk^cSc ^^^^ 

selbst kennt KGK D ec und bekommt von einem Terminal neben den Nutzdaten data und dem Kryptoeramm Cffie 
Kommandos TRANSFER). Nun kann die Karte das Kryptogramm C uber die Nutzdaten selbst berechhen 
ma a c<Srta)?= C^^' Tenninal = = ^""-PCKKobc™. ItaSfSS) = = 

Die Karte vergleicht nun das selbst berechnete Kryptogramm C mil dem vom Terminal berechneten Kryptoeramm C 

muB s,ch zur AusfUhrung der "Entwerten" Operation gegeniiber der Karte durch Kenntnis eineTschiaSk K ^TTn 

KE^T K r Pr0 ^ iUien,ng d !! * hlaSS t k ^ k ^ d - Augreifer lediglich «JS^lS£SSSS££ 
durchfiihren. Dieser Vorgang wud jedoch in der Karte protokolliert Die Dokumentation eothalt eine eindeS sZ 
quenznummer, die Ehtwertung und die Terminal ID: Die VAS-Applikationen nutzen die Si^Se^taVAf 

Ju^TnT-? 0 gr f aU L VAS : Daten zu reglementieren. Die AusfUhrung von VAS spezinsche^nkuonen ^d 
durch die Definition von Zugnffsrechten auf berechtigte Parteien beschrankt rumcuonen wird 

Im aUgemeinen muB es fur jede VAS-Applikation offentlich zugangliche Datenbereiche (z. B. zum Auslesen von Wer- 
ten nut einem WaUet) und private Datenbereiche des verantwortlichen VAS-Provider geben, die er vordeSriff durch 
andere schutzen kann (z. B. interne Verwaltungsdaten). er voraem ^gntt durch 

DaKarten nach ISO 781 6-4 fur einzelne Records von Elementary Files (EF) keinen dlfferenzierten ZugrifFsschutz'bie 
y^^^Z^SJ:^ eiDCn - °-'eUung unterschiedlicher SSSSSS, 

,rhm^! SS-^^ ^PP^f™**™™ Punktespeicher, Ticket, Ausweis und Datenspeicher differenzierter Zugriffs- 
schutz durch die Aufteilung der VAS-Daten in vier Elementary Files realisieren, wie in Fig. 6 dargesteUt 
Die v ie r Elementary Files enthalten folgende Daten bzw. werden folgendermaSen geschutzt 
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Tabelle 3 
Ubersicht Dateien 



Feld 


In halt 


Typische Nutzung 


Zugrrffsschutz H 


|EF_KEY 


Enth§lt die 
Schlussel 

Klvasp* Krvasp 
die nur der 
VAS-Provider 
kennt 

(Anmerkung: 
Pro VAS- 
Apptfkation 
und optional 
pro Karte 
vergibt der 
VAS-Provider 
jewefls ein 
SchlQsselpaar 
) 


Em VAS-Provider mu& sich mit 
Klvasp authentisieren, bevor er 
VAS-Daten schreiben darf in 
EFJNFO, EFJNTERNAL und 
EF_VALUE bzw. bevor er Daten 
aus EFJNTERNAL lesen darf. 

Ein Terminal mud sich mit 
Krv AS p authentisieren, bevor es 
VAS-Daten aus EF INFO. 
EF_VALUE lesen darf. 




EFJNFO 


Nicht interne 
Informationen 
Gberdie VAS- 
Appiikation 


• Tlcketinformationen 

• Bonusprogramm Information 

• Ausweisinformationen 

• Parkschein Infonmationen 


Die Inhalte dieser Dateneinheit 1 
k6nnen nur vom VAS-Provider J 
geschrieben (externe 1 
Authentifizierung durch Kenntnis 1 
von Klvasp) werden. Lesen soil I 
nur an Terminals, die Qber Krvasp 1 
Oder Kgo verfGgen, m6glich sein, 1 
oder der Karteninhaber gibt einen J 
korrekten PIN ein.. per PIN- J 
Schutz kann von Karteninhaber 
deaktiviert werden.) I 


] fcr_JIN 1 fcKNAL 


Interne Daten 

derVAS- 

Applikation 


Interne Zahler, Kontostande, 
Steuerinformationen, zusStzliche 
Keys fdr: 

• Bonusprogramme 

• Rabattstaffelungen 

• Verdeckte Ausweismerkmale 

• Codes 


Die Inhalte dieser Dateneinheit I 
konnen nur vom VAS-Provider I 
beschrieben und gelesen werden. j 
Der ZugrifFsschutz basiert auf ex- 1 
terner Authentifizierung durch I 
Kenntnis von IWsp. 1 


EF_VALUE 


Werteinherten 
der VA5- 
Applikatlon 

• 


Diese Dateneinheit enthait 
ouchbare werte einer VAS- 
Provider Applikation. 

• Kontostand 

• Restwert Fahrschein , 

• Guthaben 

> NutzungszShler 

1 


Nur der VAS-Provider kann diese 
Werte explizit schreiben (externe 
Authentifizierung durch Kenntnis j 
von Klvasp)- Implizit kann der Wert 
durch den Befehl .Entwertung" 
von einem Partner verringert j 
werden, der zur AusfGhrung der j 
Funktion durch den VAS-Provider 
berechtigt wurde (durch Signatur 
der Operation Entwertung mit j 
Kd FC ). Lesen wie bei EF INFO. | 
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30 



35 



40 



45 



50 



55 



60 



65 



Diese Struktur von Elementary Files (EF) unterstutzt die gleichen differenzierten Zugriffsrechte fur alle Applikations- 
klassen. 

Indem nun gleicbartige Applikationsklassen zu jeweils einer Implementierungsklasse, die Anzahl und GroBe der Ele- 
mentary Files festlegt, zusammengefaBt werden, laBt sich ein Speicherverschnitt durch unterschiedlichen Platzbedarf fur 
Applikationen minimieren. Die Applikationsklassen Punktespeicber und Ticket benotigen die gleichen Resourcen 
EF_KEY, EF_INFO, EF_INTERNAL, EF_ VALUE und werden daher zusammengefaBt zur Implementierungsklasse 
"DF_PT". Fiir die Applikationsklassen Ausweis und Datenspeicher geniigen die Elementary Files EFJECEY und 
EFJNFO und werden daher zur Implementierungsklasse "DF_AD" zusammengefaBt. AnzahlmaBig betrachtet: Es gibt p 
Objekte der Implementierungsklasse DF_PT und a Objekte der Implementierungsklasse DF_AD, in die V/\S-Appiika- 
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schbeBucb mdirekt durch die Anwenduhg des TRANSFER Befehls mdglich, der eine Signatur miS Shen 
K DEC verlangt D.ese Implemenderungsklasse besteht aus genau einem Eintrag in. Eleme^H™ EF TRANsS 

nt^:^ 

^^%l£^ D d ^^^ " b des VAS-Container. Diese Implementierungs- 
Die Bereitstellung dem Speichermodells kann auf zwei Arum erfolgen. Die Wahl bangt von der KartenplaUform ab: 
- Feste Partitionierung des Speicherbereichs fur den VAS-Containen 

OH.t e ^ 1 ? m f^ en, !l 8 i klaSSen D T F - PT Und VP -^ D vom ^suer jeweik ihre maximale Anzahl p bzw a von 

SKEwSKS'S v SSS??* *t? 11111 ^ Befeh,en geladen - 1* 

wir nut KJj bzw DF_ADj. VAS-Apphkationen kdnnen zu einem spateren Zeitpunkt in freie also nicht von an 
a^n^AT^ 

Der Issuer legt also die Anzahl von moglicben Objekten der beiden Implementierungsklassen nach seinen eieenen 
Bedurfmssen fest; dies kann eventuell nicht mit dem tatsachlichen VAS-Nutzungsverhalten te SnC 
uberem^mmen Die Aufteilung wird uber den gesamten Lebenszyklus der Karte beibehalten Erne VA^TnnSa 
Uon wird m em Objekt ge aden, das von einer geeigneten Implementierungsklasse ist So kann z 1 I eine VAS Ado- 
hkation, d.e emen Auswets darsteUt, auch in einem Objekt der Implementierungsklasse F^ untemebrachtte^ 
den wenn kerne Objekte der Lnplementierungsklasse DF_AD (mehr) zur Verfugung stehen^ DieSeSung eTner 

w ^ elDem ^ erf ° lgt dUICh deD Eintra « eines Tnpels (PK der VAS-ApphkaSn FTO d^ b" 
legten Objektes, Klartextname der Applikation) in die globale Datei EF_DIR des VAS-Container DaTintfernen der 

RECO^BefeK f^TZ*^ THf>elS EF " DIR Und dCm «"*«aden 1^ (KfiSKS 

KliCORD Befehle) des von der Applikation belegten Speichers 

. ^^ZJS^SSSt 08 ™ &rt "* ta ^ * keine Erzeugung bzw. Loschung von 

- Dynamiscbes Anlegen von Objekten der Implementierungsklasse- 

Fur jede zu ladende VAS-AppUkation werden mit CREATE FILE Befehlen die fur die zugrundeliegende Imolemen- 
nerungsklasse benougten Dateien angelegt Beim Loschen der VAS-Applikation wind die vor TiRl^DFrnF 
oSenr^rM" KartC T ^ u" 6 ^ fi^igegeben. DiJmaximale Anzahl von ObJS von 
SSST ^ CXpUZit V ° m ISSUCr fetZUlegen U " d h3ng < nur vom zur Verfu^ung ste^n 
Diese Variante erfordert eine dynamische Speicherverwaltung durch das Kartenbetriebssystem. 
Im vorhegenden Ausfuhrungsbeispiel gehen wir von der ersten Variante aus, da die zweite erhohte Anforderunren *n 
J^S^SSTh? he H d H ttf0ml S L CUL StCht 6ine dynami5Che ^cherverwaltung jeTh zufve^g und 

stet, dann kann das bestebende Konzept ubemommen wenden und bietet dem Karteninhaber mehr Flexibility 

Im folgenden werden die Datenstrukturen und Kommandos voigestellt, mit denen sich der VAS-ContWr „nH Hi. 
f£2?i 5SS v A U ^ karte " nd « 0 Systemkolponenten realisier" , Ltn Au^ZZr^n Sir 

nTbeschiTben VAS-Operafconen festgelegt, die die jeweilige Interaktion zwischen VAS-Container und Termi- 

Fiir die Implementierung wird von folgenden Voraussetzungen ausgegangen: 

" Handlerterminal stellt jede Karte, unabhangig von der Plattform, die gleiche Daten- und Kommando- 

schmttstelle zur Verffigung Die erforderlichen Kommandos sind daher in ihrer Kodierung eindeutig beSSbeT 
■ - Servtcetermmak smd fahig, die Kartenplattform zu erkennen. Die Funktionalitat kJdahShSfiSi 
Kommandos der P attform erreicht werden. Diese Vorgange sind daher teilweise informell beschrieben We d5e 
FunkUon bereitgesteUt wird ist dem KartenhersteUer freigesteUt. . 

*rfi!S 7 ^. erden , hie f zu fehematisch verschiedene Implementierungsklassen des VAS-Containers dargestellL Fig, 8 
Der Zugnff auf die Dateien des VAS-Container wird explizit durch folgende Access Conditions (AC) eingeschrankt: 
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Tabelle4 
Zugriffsbedingungen 



Datei 




LesezugnTT 


ocnreiozugriff 


LJi VnO 


IS 

*SO 


Nbv 


NEV 


cr 1 u 


is 


A I \ A/ 

ALVY 


Kso 


cc nic? 
tzr uirv 


IS 


ALW 


Kso 


globale KEYs 


Kso 


NEV 


Kso 


PIN 


K so 


NEV 


Kf?o 


EF VERSION 


Kso 


ALW 


Kso 










EF SEQ 


Kso 


ALW 


Kso 


EF TRANSFER 


K so 


ALW 


Kso 










DF_X 

/Y-DT DT AH A r\ 

(A-P I i,...,PT Dt AD 1f .. M AD a 
) 


K so 


NEV 


NEV 


EF KEY 




NEV 


Kso 


EFJNFO 


Kso 


PIN Oder Kr VA sp 
oder Kso 


Klvasp 


EF INTERNAL 


K so 


; K LVASP 


Klvasp 


EF_VALUE 


Kso 


PIN oder Krvasp 
Oder K sr> 


Klvasp 



Dabei haben die AC folgende Bedeutung: 



- ALW (Always) = Der Zugriff des Kommandos auf die Datei ist immer erlaubt. 

- NEV (Never) = Der Zugriff des Kommandos auf die Datei ist nie erlaubt. 

- K SO = Vor Zugriff mufi externe Authentifizierung des System Operator mit dem Schliissel K so erfolgen. 

~ ^VASP = Vor Zugriff muB externe Authentifizierung des VAS-Provider mit dem Schlussel K^ V asp erfolgen. 
_ K RVASP = Vor Zugriff muB externe Authentifizierung eines vom. VAS-Provider autdrisierten Terminals mit dem 
Schlussel K RVASP erfolgen. 

- PIN = Vor Zugriff muB die korrekte PIN durch den Karteninhaber eingegeben werden und im Klartext mit dem 
Kommando VERIFY an die Karte geschickt werden. 

- PIN oder K RVASP oder Ksq = Vor Zugriff muB entweder die korrekte PIN durch den Karteninhaber eingegeben 
werden, oder es erfolgt eine externe Authentifizierung durch den VAS-Provider mit Kr V asp oder durch den System 
Operator mit K so . ; 

Dabei ist anzumerken, daB die Oder-Verkniipfung von Zugriffsrechten, wie oben beschrieben, in Kartenbetriebssyste- 
men in der Regel nicht vorgesehen isL Eventuell bedeutet dies besonderen Implementierungsaufwand. (Alternative: spe- 
zielles READ Kommando mit implizit festgelegtem Sicherheitsattribut). 

Datenfelder innerhaib der Records von Elementary Files werden nach foigenden Formaten unterschieden: ASCII, Bi- 
nar, BCD, Datum, Formatstring. v ' 

Datenelemente vom iyp ,, Formatstring rt enthalten VAS-Daten in gepackter DarsteUung, die dem Karteninhaber am 
Terminal angezeigt werden konnen. 

Zur optimalen Speicherausnutzung werden Klartext und binare Daten gemischt und uber Formatiermakros darstellbar 
gemachL 

SamtUche Elementary Files (EF) des VAS-Container sind nach ISO 78 1 £4 deflniert als lineare formatierte EF Dateien 
mit Records konstanter Lange (linear fixed record files). 

Das Elementary File EF_ID des DF_VAS besteht aus einem Record, der die VAS-Container ID enthalt. 

Das Elementary File EFJDIR des DF_VAS besteht aus nr DIR Records. Fiir jede in den VAS-Container geladene VAS- 
Applikation wird in einem Record des EF_DIR ihr Proprietary Identifier Extension (PDQ und ihr physikalischer Spei- 
cherplatz (FID des DF_X, in den die Applikauon geladen wurde) festgehalten. Die PIX identifiziert z. B. als Kennziffer 
die Applikation und den Service-Provider, dem die Applikation zugeordnet ist. 

Die Eintrage im EFJDIR werden am Service Terminal des System Operators dynamisch angelegt. Records ohne Ein- 
trag werden mit einem leeren TLV Objekt '61' angelegt. 

Beim Laden einer VAS-Applikation wird zunachst ein freier Speicherbereich der fur sie passenden Implementierungs- 
klasse gesucht, bestimmte VAS-Daten dort eingetragen und schlieBlich im EFJDIR ein neuer Record erzeugt. 

Beim Loschen einer Applikauon muB in EF_DIR entsprechend ein ieeres TLV Objekt geschrieben werden. 
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JZSST" ^ EF - VERSI0N deS DF - VAS aus — Record, der eine Versionsnummer des VAS-Con- 

t ,hfl!'tr il T kanD V ° n Terminals ^ benUtzt werden > verschiedene VAS-Container- Varianten und/oder ver- 
schiedene Software- Versionen zu unterscheiden r ver 

t ra^„ E t!Tart entary ^ ** DF " VAS be8teht 3US einem ReCOrd > der ^ Nun ™* d <* "-hsten Transferfeldein^ 

i m ^Trf^^?r^? Elg ^ UngS ^° mmando TRANSFER ausgelesen. Dieses Kommando erzeugt daraufhin 
un Transferfeld EFJTRANSFER einen Record, in den u. a, die Sequenznununer aus EF SEQ ubertragen wkd. Zusam- 

SSL ISSST'V^^ f 11 ^ daB jedCr ReCOld aus dem ^ferfefd nur einrnalLtnZm^ w^d 
U J^^SS^^J^^ k - * einr.alige Entnahme von (Original-) 

Im folgenden soli nun genauer auf den Transferspeicher eingegangen werden 

Der Transferspeicher wird innerhalb des VAS-Containers aneeleet und umfafit nr„. p ( ^ P rr- # - 

den Records dieses Hies enthalten Transferdaten, die vom TT^SFER^m^^^^ 

E^SSSX^SST^ ZWiSChen VAS - A ^ likati °- * «* * ^herung von VAsSSSL 
Die Belegung der Datenfelder durch den TRANSFER Befehl geschieht durch einen "Last-recently-used" Algorithms 

£££££ der Datei kaM durch Suchen des ldeinsten Wertes in den ersten 2 S5- 2S23E 

In rfTf^ m r ^ Befehl "' IAKE " T^sferspeicher als entnommen und/oder entfemt markiert werden 

In jedem FaU erfotgt das Loschen von Daten un Transferspeicher durch Oberschreiben mil neuen Daten 

Jeder Record im Transferspeicher enthalt beispielsweise ein Verfallsdatum, die Terminal-ID, die PK die Seouenz- 
nummer und eventuell weitere Daten. ' ' ale ^equenz- 

Jedes Elementary File EFJNFO innerhalb von Verzeichnissen DF_X (mil X = PT, PT AD, Ani^, 
aus einem Record, der das Verfallsdatum sowie allgemeine VAS-Daten einer VAS-Applikauon enthalt' Behpielsweise 
kann die Art ernes Tickets CEinzel- oder Streifenfahrschein) Oder der Kn^geo^ Mer S^geben S 
jedoch zumindest emen Klartextnamen der Applikation enthalten, der fur die Operation Ansehen VAS-Ap"Sonen 

"D.W FF 5 n , K ^ ^ ^ VAS "! r0 r ider dUrCh eXte ™ e Ve-hlfisselungsalgorithmen schSen 

Dieses EF ist lesbar, wenn eine exteme Authentifizierung mit Kc n oder &,v,™ erfolet ^Her At v art „:„hi. - 

Falle eines aktivierten PIN-Schutzes eine korrekte PIN eingibt ^ VASP 8 Kartenmhaber .m 

Jedes Elementary File EFJQNTERNAL innerhalb von Verzeichnissen DF X (mit X = PT, PT AD, ATI V 

tTn w'T dW L nten,e VAS " Daten des VAS-Provider iiber seine geladene VAS^App'likation ennXn 

kann Weder Kartenmhaber noch ein anderer VAS-Provider konnen diese internen Daten lesen entnaiten 

Jedes Elementary File EF.VALUE innerhalb von Verzeichnissen DF_X (mit X = PT, PT AD AD 1 
steht aus einem Record, der ein ganzzahliges Wertfeld der VAS-Daten enthalten kann. Diets' EF ist lesbar' wenneSe ex-" 

£Tl£2£ ^J^^*™"* ?*W °** ^ Karteninhaber im Falle eines aktivierte"' SSXEL 

erne korrekte PIN bzw. ein korrektes PaBwort eingibt. 

Die folgenden Schlusselfelder werden vom VAS-Container oder von der VAS- Applikation benutzt. Im folgenden wird 
von einer reinen DES- Verschlusselung ausgegangen. D.h. samtliche Schlussel des VAS-Containers sind DE?-s7hlS 
und sind in 8 byte codiert (einschlieBlich Paritatsbits) acniussei 

.aSS^^SSSSSS^ ** ™-Ap^™n kannen folgende Schlussel durch ihren KTD 

Tabeile5 
Schlussel VAS-Container 



50 



55 



KEY 


KID 




'00' 


Kaijt 


•or 


K SIG VAfiO ,. 


'02' 


KGKnpr: 


'03' 



Jeder Schlussel ist mit einem Fehlbedienungszahler verkniipft. Dieser registriert fehlgeschlagene Aumentiimerunes- 
relehTfst 11111 SCl Und blockiert eine weiter ^ Nutzung, wenn ein Limit fur diesen Zahler eingetragen und er- 

Innerhalb der VAS-Applikation konnen folgende Schlussel durch ihren KID referenziert werden. 
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Tabeile 6 
Schlussel VAS-Applikation 



KEY 


KID 


Klvarp 


'04' 


KrvASP 


'05' 



Jeder Schlussel ist mit einem Fehlbedienungszahler verknupft. Dieser registriert fehlgeschlagene Authentifizlerungs- 
versuche mit diesem Schlussel und blockiert seine weitere Nutzung, wenn ein limit fiir diesen Zahler eingetraeen und 
erreichtist 

Der VAS-Container enthalt eine personliche Identifikationsnummer oder PaBwort (PIN). Dies wird vom VERIFY 
Kommando zur Identifikation des Karteninhabers benutzt. Die PIN ist verknupft mit einem Fehlbedienungszahler, der 
jede Falscheingabe registriert und bei Erreichen eines Limits den PIN- Vergleich spent Diese Sperre kann durch den Sy- 
stem Operator mit geeigneten Administrationskommandos zuriickgesetzt werden. Der Fehlbedienungszahler wird bei 
korrekt eingegebener PIN zuriickgesetzt 

Es gibt folgende Parameter fur den VAS-Container, die vom Kartenherausgeber gemaB dem zur Verfugung stehenden 
Platz auf einer Kartenplattform und seinen individuellen Wunschen gewahlt werden konnen: 

- p Maximale Zahl von Objekten der Implementierungsklasse DF_PT = maximale Zahl von VAS-Applikationen 
der Applikationsklassen Punktespeicher und Ticket, die gleichzeitig in einen VAS-Container geladen werden kon- 
nen; 

- a Maximale Zahl von Objekten der Implementierungsklasse DF_AD = maximale Zahl von VAS-Applikationen 
der Applikationsklassen Ausweis und Datenspeicher, die gleichzeitig in einen VAS-Container geladen werden kon- 
nen; 

- nr DIR Maximale Gesamtzahl von Objekten: nr DIR = p + a. Die Anzahl von Records in EF_DIR ist nr D T R ; 
~ nr EF_TRANSFER Anzahl von Records des EF_TRANSFER. 

Der Speicherbedarf fur die GroBen der beschriebenen Elementary Files ist: 



Globale Daten des VAS-Containers: 



Transferfeld: 

Proprietare Daten der VAS-Providen 



Wahlen wir z. B. fur die Parameter p, a und nrgpjj* R y^§pg R folgende Werte, dann ergibt sich foigender Mindestspei- 
cherbedarf fur den VAS-Container (ohne Speicherbedarf fur Erganzungskornmandos): 

Parameter Speicherbedarf 
p = 8, a = 3, nr EP TRANSF1BR = 15 2030 Byte 

p = 10, a = 5, d^"ef_transfer = 20 2758 Byte. 

Der Maximalspeicherbedarf ist wahrscheinlich um ca. 10% hoher als der Mindestspeicherbedarf. 

Im fdlgenden wird nun genauer auf die Kommandos der erfindungsgemaBen Chipkarte eingegangen. 

Das READ RECORD Kommando wird zum Auslesen von Daten aus linearen Elementary Files benutzt Die Karte lie- 
fert in der Ruckantwort den Inn alt des Records. Das EF wird durch den Short File Identifier (SFI) referenziert. 

Der Status Code '9000* signalisiert eine erfolgreiche Durchfuhrung des Kommandos; jeder andere Code wird als Feh- 
ler bewertet. 
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Byte 




EFJD 


4 


35 


EF_DIR 


9*(P+a) 




EF_VERSION 


1 


40 


EF_SEQ 


2 




Globale Keys, Pin 


64+2 




EF_TRANSFER 


48 * nr EF _ TRANSFER 


45 


EF_KEY 


(p+a)*32 




EFJNFO 


(p+a) * 62 


50 


EF_INTERNAL 


p * 10 


EF_VALUE 


P*3 
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Der UPDATE RECORD Befehl wild benutzt, um Daten in die Records eir.es linearen EF einzubringen Die Komman- 
donachncht enthalt die Referenz auf das EF, den Record und die Daten g ^omman- 

m ^ n A TT d tf, K h art " nthalt deri Statnscode. Der Statuscode '9000- signalisiert den erfolgreichen AbschluB der Kom- 
mandos. Andere Subcodes zeigen den Fehlerfall an. 

Das GET CHALLENGE Kommando fordert von der Karte eine Zufallszahl an. Die Zufallszahl wird im Zusammen- 
hang mil der dynamischen Authentinzierung im EXTERNAL AUTHENTICATE verwendet. 

Die AntworWachricht der Karte enthalt eine 8 bytes lange Zufallszahl und den Statuscode. Der Statuscode 'POOO 1 zei E t 
die erfolgreiche Ausfuhrung des Kommandos an. Andere Statuscodes zeigen den Fehlerfall an 

ExSl^ArrU^HSSiS AUTHENTICATE erlaubt die Authentinzierung eines Terminals gegeniiber der Karte. 
EXTERNAL AUTHENTICATE wird im Rahmen von VAS-Applikationen zur Authentinzierung des System Operators 
ItlS^ T tZ, , EXTC ? ,A ^ AUTHENTICATE ubertrkgt ein Kryptogramm in die Ka5 JffiSS 
vom Terminal durch Verschlusseln emer Zufallszahl erzeugt werden muB. Die Karte vergleicht das Kryptogramm mil ei- 
nem Referenz wert^ der, sie^lbst nach dem gleichen Verfahren berechnet hat Sind beide Werte gleich, so^er™ die 
Karte intern, daB die Zugnffsbedingung Authenufiziemng fur diesen Schlussel erfolgt ist. SoUteder CSnegadv 

Erre cht dieser Zahler den Wert 0, so wirdjede weitere Ausfuhrung des EXTERNAL AUTHENTICATE mit dem Status 
Authentinzierung gespent" abgewiesen. 
Die Antwortaachricht der Karte enthalt den Statuscode. Die erfolgreiche Durchfuhrung des Kommandos und die Au- 
S^ufZ!^ 8egeniiber ^ KartC WW dUrCh de " StatUSCOdC Andere StatusTodes zet 

Das Kommando INTERNAL AUTHENTICATE wird benutzt, um die Echtheit des VAS-Containers durch ein Termi- 
nal prufen zu konnen. Die Karte berechnet dazu ein Kryptogramm uber Referenzdaten vom Terminal. D^Ter^n^ - 

eSSSS vSSSESC Z*** " ** ^ ^ VO " ^ ^ ^ ***** «* « die 
Die Antwort der Karte enthalt das Kr>ptogramin und den Statuscode fur die Ausfiihrung des Kommandos Die erfole- 
^- rChfilhnJng dCS Ko ™*- wird durch den Statuscode '9000' angezeugt Anderl SW^S^c^S- 

Das VERIFY Konimando wird zur Verifikation der Karteninhaber PIN benutzt Das Kommando ubertragt die PIN Da- 

* I" t C y erglCich "* eiDem g"^^ Referenzwert durchgeruhrt wird. Sind einge- 

gebener und gespeicherter Wert identisch, so wird die Zugnffsbedingung "PIN" als erfuUt betrachtet 

K^^^l h 7 ht d f f Kart * enth5k de ° S^tuscode. Der Statuscode '9000' zeigt die erfolgreiche Durchfuhrung des 
Kommandos an. Andere Statuscodes zeigen den Fehlerfall an. * 

definTerT^^ 11 K ° mmand0 erZCUgt einen Eintrag ™ Transferspeicher. Drei Arbeitsmodi sind fiir das Kommando 

KlS^ dUr ° h Verringern VOn Werten im EF_VALUE Feld der Applikation der 

2. Erzeugen eines Eintrags im Transferfeld durch ErsteUen einer Quittung in Applikationen der Klasse Ausweis 
schS eUge " 61065 gS im 1Vansferfeld durch ErsteUen eines Gutscheins in Applikationen der Klasse Gut- 

Der Arbeitsmodus wird durch die Karte automatisch ausgewahlt: Wird der Befehl innerhalb eines selektierten AppU- 
ffi?? v rf^M^ff 1 ! 31 d3S Vorhandensein eines EF-VALUE uberpriift. Bei vorhandenem EF VALUE 
fuhrt die Karte den Befehl I un Modus 1, ansonsten im Modus 2 durch. Ist innerhalb des VAS-Containers kein Applikati- ' 
ons-DF ausgewahlt, wird Modus 3 benutzt yy 

Das Terminal versorgt die Karte beim Aufruf des TRANSFER Kommandos mit den folgenden Daten: 

- Aktuelles Datum 

- VerfaUsdatum fiir den Eintrag im Transferfeld 

- Identification fiir das Terminal, welches diesen Eintrag erzeugt 

- Nutzdaten fur das Transferfeld 

- PIX der VAS-Applikauon (nur Modus 3) 

- Anzahl abzuziehender Einheiten (nur Modus 1) 

- MAC fiber die o.g. Daten, die Sequenznummer und die VAS-Container Nummer. 
Die Karte fuhrt beim Aufruf des TRANSFER Kommandos die folgende Sequenz aus: 

1. Suchen nach einem freien Eintrag im Transferspeicher. (Die folgende Aufzahlung gibt absteigend die Prioritat - 
wieder, in welcher vorhandene Eintragungen uberschrieben werden soUen: "Eintrag als entfernt markiert" "Eintrae 
als entnommen markiert" und "VerfaUsdatum erreicht", "VerfaUsdatum erreicht"). ' 

2. Anhangen der PDC an die Daten vom Terminal in den Modi 1 und 2. 

3. Anhangen der Sequenznummer an die Daten aus Schritt 2. 

4. Anhangen der VAS-Container ID an die Daten aus Schritt 3. 

5. Ableiten des KGKdec PIX durch Verschlusseln der PDC unter dem KGKqec. 

6. Ableiten des Kqec durch Verschlusseln der Terminal ID unter dem KGK DEC PIX . 

7. Erzeugung des MAC uber die Daten aus Schritt 4. 

8. Vergleich des MAC aus Schritt 7 mit dem MAC vom Terminal. Sind die Werte unterschiedlich, bricht die Karte 
die Funktion ab und verringert den Fehlbedienungszahler fur den KGKdec. 
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9. Fur Modus 1: Priifung des Wertfeldes EF_ VALUE im Verzeichnis, in das die Applikation geladen wurde. Sind 
nicht geniigend Einheiten in diesem Feld vorhanden, bricht die Karte die Funktion an dieser Slelle ab. Anderafalls 
wird das Wertfeld in der Applikation urn den Betrag vermindert 

10. Zusammenstellen der Kommandonachricht 

11. Inkrementieren des Inhalts von EF_SEQ um 1. 

Die Kommandonachricht enthalt beispielsweise Felder mit einem Verfallsdatum, der Terminal ED, den Transaktions- 
daten, ein Feld fur den Betriebsmodus (enthalt z. B. im Modus 3 die PDC), sowie ein Kryptogramm. 

Das Kryptogramm wird unter Verwendung des Schliissels K DEC berechnet, wobei die Daten, iiber die der MAC gebii- 
det wird, beispielsweise die Transakuonsdaten und die Terminal-ID umfassen. 

Die Antwortnachricht des TRANSFER Kornmandos umfaBt im Erfolgsfall einen 8 Byte ianges Datenfeld und den 
2 Byte langen Statuscode '9000'. Antwortnachrichten mit einem von ^OOO* verschiedenen Statuscode werden als Fehler- 
code interpretiert. Das Datenfeld der Antwortnachricht enthalt im fehlerfieien Fall (d. h. insbesondere war das Krypto- 
gramm der Kommandonachricht korrekt) das mit Kq^ verschlusselte Kryptogramm der Kommandonachricht. Dadurch 
wird implizit (anstelle einer intemen Authentifizierung mit K AUT ) ein Echtheitsnachweis durch den VAS-Container er- 
bracht. _ 

Das Kommando TAKE dient zur Entnahme von Objekten aus der Implementierungsklasse EFJTRANSFER. Tech- 
nisch bedeu tet d ie Ausfuhrung des Kornmandos TAKE das Auslesen eines anzugebenden Records aus der Datei 
EFJTRANSFER, wobei der Record in der Datei so lange verbleibt, bis der Speicherplatz fur neue Eintrage benotigt wird, 
der Datensatz wird als enthommen markiert. Technisch gesehen kann jeder das Kommando TAKE nutzen, um einen Da- 
tensatz zu entnehmen, nach den R&R sollte dies jedoch nur ein VAS-Provider tun, fur den der Datensatz bestimmt isL 

Fur den Entnahme vorgang kann folgendes angenommen werden. Der VAS-Provider, der einen Gutscheiri oder eine 
Quittung entnehmen will, durchsucht den TVansferspeicher nach einem passenden Datensatz (z. B. durch das Kommando 
SEEK oder durch explizites Lesen jedes Records). Der Datensatz wird in jedem Fall gelesen und eventuell inhaltlich ge- 
priift. . 

Die Ausgabe des Datensatzes in der Antwort ist daher nicht notwendig. Es kann weiterhin angenommen werden, daB 
die Nummer des Records bekannt isL 

Das Kommando TAKE stellt folgende Modi bereit: 

- Entnahme mit gleichzeitigem Verinerk, daB die Daten ungultig geworden sind. 

- Entnahme ohne vorstehenden Vermerk. Die Daten bleiben weiterhin giiltig. 

Die Kommandonachricht enthalt Felder mit Terminal-ID, PDC der Applikation und eine vom Terminal generierte Zu- 
fallszahl. 

DiePDC im Kommando bezeichnet die entnehmende Anwendung. Sie darf verschieden sein von der PDC des Daten- 35 
satzes, der entnommen wird. Sie dient ausschlieBlich zur Ableitung von K^ec des entnehmenden Handlerterminals. 

Die Antwortnachricht der Karte enthalt ein Kryptogramm Cj mit K SIGVASC iiber die Daten des in der Kommando- 
nachricht angegebenen Records des Transferfeldes und die VAS-Container ID, ein Kryptogramm C 2 mit K DEC des ent- 
nehmenden Terminals iiber C{ und die Zufallszahl aus der Kommandonachricht. Die Antwortnachricht enthalt zusatzlich 
den Statuscode. Der Schlussel K DEC wird wie vorher beschrieben abgeleitet. Mit dem Kryptogramm vermdge KQgc 40 
wird implizit ein Echtheitsnachweis durch den VAS-Container erbracht. Mit dem Kryptogramm C wird ein Echtheits- 
nachweis und Einmaligkeitsnachweis (da C iiber Sequenznummei, Entnommen-Bit des TransferfeloVRecords und VAS- 
Container ID gebildet werden) berechnet, den der Systemoperator verifizieren kann. 

Der Statuscode ^QOO' zeigt die erfolgreiche Durchfuhrung des Kornmandos an. Andere Statuscodes werden als Fehler 
interpretiert. 45 

Es ist davon auszugehen, daB der SO eine ATDv AS gemaB ISO/EEC 7816-5 beantragt Genauen Er beantragt eine 
5 Byte lange RIDvas fiir das VAS-System. 

Die AIDvas des Verzeichnisses DF_VAS soli lauten: AJD VAS = RID VAS • PDC DF VAS . 

Fur jede VAS- Applikation A wird gemaB RO eine 3 Bytes lange PDC A vergeben, um sie innerhalb des VAS-Container 
eindeutig mit AID A = RTD V as * P k a identifizieren zu konnen. Nach der Selektion des DF_VAS kann ein Verzeichnis, in 50 
dem die VAS-Applikation A enthalten ist, mit SELECT FELE <PDC A > ausgewahlt werden. 

Mit dem UPDATE KEY(KID, K) sei ein von der Kartenplattform abhangiges Kommando bezeichnet, mit welchem 
ein Schlussel mit Key Identifier ID durch den heuen Wert K ersetzt wird. 

Bevor eine VAS-Applikation aus einer der Implementierungsklassen DF_PT oder DF_AD (dies entspricht den Appli- 
kationsklassen Punktespeicher, Ticket, Ausweis oder Datenspeicher) durch den Karteninhaber an Hanolerterrninals ge- 55 
nutzt werden kann, muB sie an einem Serviceterminal des zustandigen VAS-Provider in den VAS-Container geladen wer- 
den. Prinzipiell ist aiich moglich, daB ein Kartenherausgeber im Auftrag eines VAS-Provider und eines SO bereits beim 
Aufbringen des VAS-Cpntainers eine oder mehrere VAS-Applikationen in den VAS-Container ladL Dieser Ladevorgang 
ist ein Spezialfall des hier beschriebenen. 

Ablauf des Ladens einer VAS-Applikation: 60 

1. Karteninhaber fuhrt eine VAS-Karte in ein Serviceterminal ein. . 

2. Das Serviceterminal priift, ob ein VAS-Container vorhanden ist: 

- SELECT FELE <AJDy AS > (Fehlermeldung wenn VAS-Container nicht selektierbar) 

- READ RECORD <SFI von EF_ID, 0> (Auslesen der VAS-Container Nummer). * 65 
Optional wird die Giiltigkeit des VAS-Containers gepruft. Dazu verlangt das Serviceterminal eine interne Au- 
thentifizierung des VAS-Containers: 

- INTERNAL AUTHENTICATE <Zufallszahl, KID von K AUT > 
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Das Serviceterminal priift die Antwort und bricht im Fehlerfall (mil Fehlermeldung) ab 
3 Das Servicetenmnal steUt dem Karteninbaber mehrere Optionen zur Auswahl. Eine davon lautet Laden VAS- 
Apphkauon. Diese wahlt der Karteninhaber aus. Nun wenlen dem Karteninbaber alle VAS-Applikationen, die an, 
Serviceterminal geladen werden konnen, angezeigt, und es wird auf eine Auswahl gewarteL Dazu wird die Opera- 
^S^^^SS^^^ ^ Karte " inhaber W5hlt — VAS-Appbkation A der Imp.emTtie- 
4. Das Serviceterminal untersucht den VAS-Container.mit der Operation Selektion einer VAS-Applikation ob die 
ausgewahJte VAS^Apphkabon mitPK bereits in der Karte geladen ist Falls ja, wird eine FehlenUdung ausge! 
geben. Falls nicht, wud gepmft, ob noch e.n Objekt der fur A geeigneten Implementierungsklasse im VAS^oniai- 

n,Vh,c fi w ,eS ^ i S " chen emeS Reoords in EF- 0 ^ B. mil dem Kommando SEEK). Falls 
mchte fxeiast, wird eine Fehlenneldung ausgegeben. Falls ein Record frei ist, enthalt dieser eine FID™ ' eines 
DF_X, in das kerne VAS-Applikation geladen ist. "-DF.X 
5^ Das nachste freie Objekt der fur A geeigneten Implementierungsklasse wird belegt fur die VAS-Applikation A 
Dabe, erfragt zunachst das Serv.cetenninal offline vom VAS-Provider (z. B. durch ein VAS-Provide£sAM) zwei 
bcniussel K. LVASP und K RVASP und weist sie der neuen VAS-Applikation zu- 
- SELECT FILE <FID DFX > 
GET CHALLENGE " 



- EXTERNAL AUTHENTICATE <K so (Zufallszahl), KID von Koo> 

- UPDATE KEY <KTO von K LVAS pK LVASP > 

20 - UPDATE KEY <KID von K RVAS p,Krvasp> 

- GET CHALLENGE ^asp> 

- EXTERNAL AUTHENTICATE <K LVASP (Zufallszahl), KID von K LVASP > 

- UPDATE RECORD <SFI von EF_INFO des DF_X Daten> 

- UPDATE RECORD <SFI von EFJNTERNAL des DF_X, Daten> 
2S - Optional (Initiahsiemng): UPDATE RECORD <SFI von EF_VALUE des DF_X Daten> 

fprY aCh T^ m eTfol &™ ch t^ Schreiben in die EFs wird vom Serviceterminal die Operation Eintrag VAS-Applikation 
<PIX A FID DF _x> ausgefuhrt, die das DF_X nut dem PDC A verbindet und so SELECT FILE mittels des PDC A (nach 
der vorhengen Selektion mit SELECT FILE AIDv AS ) ermoglicht. A ■ 

Der mit dem Transferspeicher zur Verfugung gesteUte Mechanismus laBt sich z. B. von VAS-Providern mitzen die In- 
tra- oder Intersemces ohne proprietare DF-Strukturen abwickeln mochten. Ein Karteninbaber muB dann insbeLondere 
vor der Benutzung emer VAS-Appl kation diese nicht erst an einem Serviceterminal laden. Er kann dagegen d^kt am 
Handlertermmal sich einen Gutschem Oder eine Quittung ausstellen und dies an einem anderen Terminal erf fatten (durch 
die Operation EnUiehmen) lassen oder den Gutschein bzw. die Quittung nur einfach vorweisen (durch Lesen). Das Laden 
emer VAS-Apphkation der Implementierungsklasse EF_TRANSFER wird daher implizit durch Aufbringen von VAS- 
Daten reahsiert bzw. auf diese Operat.cn zuriickgefuhrt. Hierzu wird auf die spater folgende Beschreibung des Erwer- 
bens der ImplemenUerungsklasse EF_TRANSFER verwiesen. • 

Nachfolgend wird der Ablauf der Operation des Eintrags einer VAS-Applikation beschrieben 
,^ D p e VA^ApBtation in den VAS-Container geladen, ist einem Terminal der physikalische Ort unbekannt, in wel- 
KaTenhe^ ,T - = 7*" ■ " ?V ' V ^a.^ ^-Appbkation bzw. ob sie uberhaupt geladen ist Aus Sicht des 
Kartenherstellers sind zwei mogliche Implementierungsweisen mogbch, die getrennt gepriift werden sollen- dabei ist 
insbesondere die Konsistenz zum ZKA-Standaid zu beachten. 

Der erste Fall: ZugrifF auf EF_DIR moglich 
Folgende Voraussetzungen sind zu erfullen: 

Es gebe standardmaBig in der Kartenplattform ein EF.DIR (z. B. unter DF_VAS), in dem AIDs den FIDs der 
Dt_X zugeordnet sind, m denen sich VAS-Applikationen aktuell befinden. 
50 - Dieses EF_DIR ist fiir jeden lesbar (AC von READ RECORD: ALW). 

. - Wird eine VAS-Applikation A mit PLK A vom System Operator in ein' freies (uhbenutztes) DF_X geladen d h 
„*/°_ dencn Elementary Files dieses DF_X beschrieben (kein CREATE FILE !), dann soli durch ein UPDATE 
RECORD die Datei EF_DIR um den Eintrag PDC A erweitert werden konnen, der auf dieses DF X verweist mit 
FID X . Die AC von UPDATE RECORD sollte daher eine exteme Authentisierung mit dem Schlussel Kc n erzwin- 
55 gen. . ~ ^ u 

- Wird der Befehl SELECT FILE <PK A > nach der vorherigen Selektion von DF_VAS an die Karte ubermittelt, 
muB das DF_X, in das eine VAS-Applikation A geladen. ist, direkt selektierbar sein. 

- Wenn eine VAS-Applikation A, die in DF_X und den darunterliegenden Elementary Files geladen ist, auf 
Wunsch des Kartemnhabers an einem Service-Terminal geloscht werden soil, werden.die entsprechenden Dateien 

60 nicht mit DELETE FILE geloscht, sondem die eingetragenen Daten lediglich mit Dummy- Werten uberschrieben 

Danach soil aus EFJDIR der Eintrag PDC A (genauer das Paar PDC A und der Verweis auf DF X) geloscht werden 
konnen (z. B. durch UPDATE RECORD mit vorheriger externer Authentisierung mit dem Schlussel Kc n ) 

- Da die Anzahl der DF_X fest ist, ist die Anzahl der Records von EFJDIR bekannt, ' 

65 Ist dieser Ansatz realisierbar, ergibt sich folgende Konsequenz: 

- Ein nach Selektion von DF_VAS direkt erfolgendes Selektieren einer VAS-Applikation mit SELECT FILE PIX A 
ist moglich. . - - a 
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Der zweite Fall: Zugrifif auf EFJDIR nicht moglich 

Steht bei der Kartenplattform kein EFJDIR zur Verfiigung oder ist kein lesender und schreibender Zu griff auf dieses 
EF_DIR - wie im obigen Abschnitt dargesteilt - moglich, soli es unter DF_VAS eine Datei EF_VASDIR geben, in der 
vom System Operator durch explizite UPDATE RECORD Befehie (nach vorheriger exterher Authentifizierung mil K so ) 
ein Bezug der PDC A geladener VAS-Applikationen zu ihrem physikalischem Speicherplatz in einem DF_X hergestellt 
wird. Das Lesen und Loschen von Records aus EF_VASDIR soli wie vorher beschrieben moglich sein. 

Der Ablauf der Operation Eintrag VAS-Applikation lauft wie foigf 
Eine VAS-Applikation A mit PIX A wurde vorher in ein freies DF_X mit FTD DF X geladen. Die Nummer des Records mit 
FED DF x wurde vom Serviceterminal vermerkL 

1. SELECT FILE <AID VAS > (Fehlermeldung wenn VAS -Container nicht selektierbar) 

2. GET CHALLENGE 

3. EXTERNAL AUTHENTICATE <K so (Zufallszahl), KID von K so > 

4; UPDATE RECORD <SFI von EF_DIR des DF_VAS\ Nummer Record mit FTD DF X , PDC A , FED DFX >. 

VAS-Applikationen der Implementierungsklassen DF_PT oder DF_AD konnen nur an Serviceterminals (da unter Ho- 
heit des System Operator) auf Wunsch des Kartehinhabers geloscht werden, VAS-Applikationen der Implementierungs- 
klasse EF_TRANSFER konnen uberall und von jedem geloscht werden. Beim Loschen zu unterscheiden sind VAS-App- 
likationen der Implementierungsklassen DF_PT und DF_AD bzw. der Implementierungsklasse EF_TRANSFER. 

Ablauf des Loschens einer solchen VAS-Applikation fur die Implementierungsklasse DF_PT oder DF_AD: 

1. Der Karteninhaber fiihrt eine VAS-Karte in ein Serviceterminal ein. 

2. Das Serviceterminal priift, ob ein VAS-Container vorhanden ist: 

- SELECT FILE <AID VAS > (Fehlermeldung wenn VAS-Container nicht selektierbar). 

- READ RECORD <EFJD> (Auslesen der VAS-Container ID). 

3. Das Serviceterminal stellt dem Karteninhaber mehrere Optionen zur Auswahi. 

Eine davon lautet Loschen VAS-Applikation. Diese wahlt der Karteninhaber aus. Nun werden dem Karteninhaber 
alle VAS-Applikationen aller Implementierungsklassen, die im VAS-Container geladen sind, angezeigt, und es wird 
auf eine Auswahi gewartet Dazu wird die Operation Ansehen VAS-Applikationen aktiviert. Der Karteninhaber 
wahlt eine VAS-Applikation A der Implementierungsklasse DF_PT oder DF_AD mit AID A aus. Das Objekt, in 
dem die VAS-Applikation geladen ist, heiBe DF_A. 

4. Nach der Selektion des DF_A authenusiert sich das Serviceterminal: 

- SELECT FILE <PDC A > 

- GET CHALLENGE 

- EXTERNAL AUTHENTICATE <K so Zufallszahl), KID von K so >. 

5. Nun wird der Inhalt der Dateien aus DF_A geloscht (fur EF_KEY, EF_INTERNAL und EFJVALUE sind der 
K LVASP notwehdig, deshalb wird dieser zuerst vom System Operator geloscht): 40 

- UPATE KEY <KTD von K LVAS E> "00- • -00"> 

- UPDATE KEY <KED von K RVASP > "00. . .00"> 

- GET CHALLENGE 

- EXTERNAL AUTHENTICATE <K LVASP (Zufallszahl), KID von K LVASP > ... 

' - UPDATE RECORD <SF1 von EFJNFO des DF_A, n 00. . .OO^ 45 

- UPDATE RECORD <SFI von EF__INTERNAL des DF_A, "00. . .00"> 

- UPDATE RECORD <SFI von EF_ VALUE des DF_A, "00. . .00 n >. 

6. Nach einem erfolgreichen Schreiben in die EFs wird abschlieBend vom Serviceterminal der Eintrag der VAS- 
Applikation aus EFJDIR geloscht: 

- SELECT FILE <AED VA s> (Fehlermeldung wenn VAS-Container nicht selektierbar) so 

- UPDATE RECORD <SFI von EF_DIR des DF_VAS, Nummer Record mit FID DF _ A "00. . .00", FDD DF _ A >. 

Die Verbindung von PDC A zum DF_A wird dadiirch aufgelost, so daB SELECT FILE mit dem PDC A nicht mehr mog- 
lich ist. 

Nun fur die Implementierungsklasse EF_TRANSFER: 55 
Eine VAS-AppUkation der Implementierungsklasse EF_TRANSFER soli nach R&R nur auf expliziten Wunsch eines . 
Karteninhabers an einem Handlerterminal oder Serviceterminal geloscht werden (auch wenn dies technisch durch beide 
moglich ware). Das Loschen eines Objektes aus EF_TRANSFER wird insbesondere dann notwendig, wenn der Trans- 
ferspeicher keinen Platz mehr enthalt fur die Speicherung eines neuen Objektes (z. B. einen Gutschein oder eine Quit- 
ting). Das Loschen geschieht immer indirekt uber das Erganzungskommando TAKE. Dieses Kommando markiert nur 60 
ein Objekt als entfernt Damit ist es zum Uberschreiben durch ein nachfolgendes Erganzungskommando TRANSFER 
freigegeben. 

Ablauf des Loschens dieser VAS-Applikation: 

1 . Der Karteninhaber fuhrt eine VAS-Karte in ein Terminal ein, welches den Inhalt von EF_TRANfSFER darstellen 65 
kann (Spezialfall yon Operation Ansehen VAS-Applikationen). 

2. Das Terminal priift; ob ein VAS-Container vorhanden ist: 

- SELECT FILE <AIDv A s> (Fehlermeldunjg wenn VAS-Container nicht selektierbar) 
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-> " ^EAD RECORD <SFI von EFJD, Q> (Auslesen der VAS-Container ID). 

3. Das Terniinal steUt dem Karteninhaber mehrere Optionen zur Auswahl. Eine davon lautet Loschen VAS-Aonli 
kation. Diese wahlt der Karteninhaber aus. Nun werden dem Karteninhaber zuriundestens L^lAnoUkaJonen" 
der ImplemenUerungsklasse EF_TRANSFER angezeigt, und es wird auf eine Ausw^TgewamT DteSS S 
e,nen Spez.alfall der Operation Ansehen VAS-Applikationen reahsiert. Der KmeninhabefS L O^ie^to 

KZSSS"? bzw einer QuiKune aus - Dieses ° bjekt *— 

- TAKE <A, ZufaUszahl, PDC, Terminal ID>. 

Qu?Zg teht ^ ^ entfemt markierte ReCOld ^ ZUf VerfB « Un S ZUr Aufhah ™ -"en neuen Gutschein oder eine 

Nachfolgend der Ablauf der Selektion einer VAS-Applikation: 
1st eine VAS-Applikation AderlmplementierungsklassenDF PToderDF AD in den va<o rv„„;». -. j .~ 
Ufa . VAS-Apphkadon geladen worden, J* zweistufig *T!S£^JE5£ So^tS 
VAS-Container selektiert und danach die VAS-Applikation mit ihrer PDC A : weraen. iLuerst wird der 

1 . SELECT FILE <AID VAS > (Fehlermeldung wenn VAS-Container nicht selektierbar) 

SSStJ^5S^ d - WQ ^ h - DaZU verlangtein krvieetermina, eine interne 

~ RECORD <SH von EF_ID, 0> (Auslesen der VAS-Container ID) 

- INTERNAL AUTHENTICATE <Zufallszahl, KID von K AUT > 

Klvasp Oder den K rvaSp fur die VAS-Applikation A enthalt Dies kann das Handlerterminal z. B. kontrouieren dS: 
- INTERNAL AUTHENTICATE <Zufallszahl, KID von K^p oder K LVASP >. 

onmH h." ^ m"' ^ fj" 6 VAS " A PP Ukati °° A im VAS-Container geladen ist, kann sie probeweise selektiert werden- auf 
handed f£ F^nneldung der Antwortnachricht von SELECT FILE kann daraus gescnlossen werden da^rSht' it 

. Eine Selektion einer VAS-Applikation der Implementierungsklasse EF TRANSFER ereibt sich imnlirit h,,^ h;„ 
Operation Ansehen VAS-Applikationen und das Speichem der Daten imTerminal. Dafas^inS Id T££mt£r 
von jedem angezeigten Objekt aus EF_TRANSFER kennt, kann per Recordnummer ein beliS Obje£ zm^Sr 
verarbeitung durcb Bezugnahme auf die Recordnummer selektiert werden ■ J 

Nachfolgend der Ablauf des Ansehens einer VAS-Applikation- 
Die Operation Ansehen von VAS-Applikationen listet an einem Serviceterminal samtliche VAS-Apolikationen der Im 
plemenuerungsklassen DF_PT, DF_AD und EF_TRANSFER auf. An einem Handlerterminal konne^ nur £ VaSaJo-" 
und onZ„?A FL^ enbe T g T k,a f 56 H V 1SANSEBI1 wer den, da fur diese kein Zugriff^hutzexisief 

bLit^^esftz^on KrvaTp" ^^^^ bzw. DF_AD, fur die das HandleLrmTnal^rSh^e 

Ablauf einer solchen VAS-Applikation: 

1. Der Karteninhaber ftihrt eine VAS-Karte (Chipkarte mit giiltigem VAS-Container) in das Terminal ein 

2. Das Serviceterminal priift, ob ein VAS-Container vorhanden ist: ierminat ein. 

" ^J^rllJ^ <ajd vas> (Fehlermeldung wenn VAS-Container nicht selektierbar) 
-READ RECORD <SFI von EFJD, 0> (Auslesen der VAS-Container ID) 

- INTERNAL AUTHENTICATE <ZufaUszahl, KID von K AUT >. 

Das Serviceterminal priift die Antwort und bricht im FehlerfaU (mit Fehlermeldung) ab 

3. Das Serviceterminal stellt dem Karteninhaber mehrere Optionen zur Auswahl. Eine davon lautet Ansehen VAS- 
Apphkationen. Diese wahlt der Karteninhaber aus. Ansenen 

4. Das Serviceterminal authentisiert sich: 

- GET CHALLENGE 

- EXTERNAL AUTHENTICATE <K so (Zufallszahl), KID von K so > 

5. Fur VAS-Applikationen der Implementierungsklassen DFJPT und DF_AD werden uber den Inhalt von EF DIR 
SSt^Tlr T r!^" V ^ A gg*^oocn selektiert und nach einer externen ^ 

dem Schlussel K so der Inhalt der einzelnen EF.INFO (oder ein Teii davon nach.R&R) sowie EF_VALUE ange- 

- Furi = 0,..., nr D i R -l 
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- READ RECORD <SH von EFDIR, i>. 

In der Antwortnachricht steht PDC A , die M 00. . .OCT ist, wenn in das entsprechende DF keine VAS-Appli- 
kation geladen ist Alternativ zum READ RECORD aus EF.DIR kann eventueU auch ein SEEK Kom- 
man do benutzt werden. 

- Wenn PDC A ungleich "00. . .00" 

- SELECT FILE <PIX A > 

- SELECT FILE <PDC A > 

- SELECT FILE <PIX A > 

- SELECT FILE <PDC A > 

- READ RECORD <SFI von EF_ VALUE, 0> 

- SELECT FILE <AH>vas > « 
6. Fiir VAS-Applikationen der Implementierungsklasse EF_TRANSFER wird der Inhalt (oder ein Teil davon nach 
R&R) des.EF_TRANSFER eines jeden Records gelesen: 

- SELECT FILE <AID VAS > 
Fur i = 0, . . nr EF ^TRANSFER " 1 

- READ RECORD <SFI von EFJTRANSFER, i> (in der Antwortnachricht steht Inhalt des i-ten Re- 
cords von EFJTRANSFER) 

- Wenn Inhalt nicht leer ist, wird der Inhalt interpretiert (z. B. entnommen/verfallen) angezeigt. 

Das Ansehen der Applikationen der Implementierungsklasse DF_PT bzw. DF_AD, fiir die das Handlerterminal Lese- 
rechte besitzt (Besitz von K RVASP ), erfolgt wie beschrieben - mit zwei Abweichungen: Zur externen Authentifizierung 25 
wird anstelle des K so , uber den nur der System Operator verfugt, der Schlussel Y^^p benutzt. Verfugt ein Handlerter- 
minal nicht uber den KGK AUT und mdchte dennoch die Echtheit der VAS-Applikationen priifen, kann das Handlerter- 
minal anstelle der internen Authentifizierung die Authentifizierung (zumindest einer) VAS-Applikation verlangen. Dies 
geschieht, wie aufgefuhrt, durch Kenntnis der Karte des entsprechenden K^y^p oder Klvasp SchlUssels. 

Fur VAS-Applikationen der Implementierungsklasse EF_TRANSFER wird der Inhalt (oder ein Teil davon nach R&R) 30 
des EFJTRANSFER jedes Records nacheinander aufgelistet, wie vorher beschrieben. 

Die Operation Interpretieren VAS-Applikationen veriauft dazu analog. Das Terminal stellt dazu dem Karteninhaber 
eine Option Interpretieren VAS-Applikationen zur Auswahl. Zusatzlich zu den Daten, die durch die Operation Ansehen 
sichtbar werden, konnen auch Dateh aus EF_INFO und EF_ VALUE, die einer Interpretation durch den VAS-Provider 
bedurfen (z. B. extern verschlusselte Daten) und Daten aus EF_INTERNAL (z. B. Meilen der vergangenen Jahre bei Mi- 35 
les & More), dargestellt werden. Dies ist jedoch nur fur die VAS-Applikationen moglich, fiir die ein VAS-Provider (nach 
seinen eigenen Vorstellungen) am Terminal geeignete Schlussel zur Verfugung stellL Zum Lesen des EF_INTERNAL ei- 
ner VAS-Applikation ist der Schlussel Klvasp (exteme Authentifizierung) notwendig. Fiir extern verschlusselte Daten 
innerhalb der Elementary Files EFJNFO, EF_INTERN und EF_ VALUE sowie des Transferspeichers EFJTRANSFER 
werden die entsprechenden Schlussel des VAS-Providers benotigt Das Termihalprogramm kann anhand der PDC einer 40 
selektierten VAS-Applikation leicht entscheiden, fur welche Applikationen Schlussel fur die Interpretation der Daten zur 
Verfugung stehen. 

Die Operation Ubertragen von VAS-Applikationen bedeutet das Ubertragen aller oder ausgewahlter VAS-Operationen 
einer Quell-Karte auf eine Ziel- Karte an einem Serviceterminal. Bedingung ist hierbei, daB im VAS-Container der Ziel- 
karte keihe VAS-Applikationen geladen sind und nach der Ubertragung auf der Quell-Karte alie VAS-Applikationen ge- 45 
loscht werden. Beides kann durch sukzessive Anwendung der Operation Loschen einer VAS-Applikation erreicht wer- 
den. AuBerdem muB die Echtheit der VAS-Karten gepriift werden und die Ziel-Karte uber ausreichend Speicherplatz ver- 
fugen. Die Operation Ubertragung selbst basiert im wesentlichen auf einer Erweiterung der Operation Ansehen von 
VAS-Applikationen, bei der zusatzlich die Daten aus EF_INTERNAL und die Schlussel Klvasp und k rvasp gelesen 
werden, und einer wiederholten Anwendung der Operation Laden einer VAS-Applikation. 

Mit den VAS-Daten wird auch die VAS-Container ID mit auf die Ziel-Karte ubertragen, damit sich VAS-Applikauo- 
nen auf der Ziel-Karte genau so verhalten wie auf der Quell-Karte. Der Grand hierfur ist, daB von einem VAS-Provider 
abgeleitete Schlussel dich auf die VAS-Container ID stutzen, die Schlussel aber unverandert kopiert werden. AuBerdem 
mdchte ein VAS-Provider seine Buchfuhrung im Hintergrundsystem nicht andern, da er VAS-Karten iiblicherweise uber 
die VAS-Container ID identifiziert. Unbedingt zu beachten ist bei der Obertragung der VAS-Container ID, daB diese sy- 55 
stemweit eindeutige Nummer auf der Quell-Karte geloscht wird. 

Urn speziell das Elementary File EF_INTERNAL und die Schlussel K^^p und K RVAS p lesen zu konnen, uber- 
schreibt das Serviceterminal nach einer externen Authentifizierung mit dem Schlussel K^ (analog wie bei der Operation 
Loschen einer VAS-Applikation) zuerst die Schlussel K LVASP und kann dann nach einer emeuten Authentifizierung mit 
K LVASP die Daten aus EFJQNTERNAL ubertragen. 

Zusatzlich zu den VAS-Applikationen der Implementierungsklassen DF PT und DF_AD muB die Datei EF_TRANS- 
FER ubertragen werden. Dazu werden mit der Operation Enmehmen nacheinander die Objekte dieser Implementierungs- 
klasse entfe rnt, d ie nicht bereits als entfemt oder verfallen markiert sind, ihre Signatur mit K SIG VASC gepruft und in das 
EF_TRANSFER der Ziel-Karte ubertragen. Auf der Ziel-Karte werden allerdings die Objekte als nicht entnommen ge- 
kennzeichnet, damit sie weiterhin gultig bleiben. 

SchlieBhch miissen noch die globalen Daten des VAS-Containers ubertragen werden. Insbesondere muB der Sequenz- 
zahler der Ziel-Karte auf den Wert der Quell-Karte eingestellt werden. 
Nachfolgend das Verfahren des Aufbringens von VAS-Daten: 
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SS!,S Che ^ ^ ^ AUfbringen V ° n VAS - Daten »» ™™ Handlerterminal, die von der Art der VAS-App- 

^ Zunachst das Erwerben im Falle der Implementierungsklasse DF_PT oder DF_AD 

DF^g^ebefw^"^ 1 ^ " d " A dCf ^p.emenuerungsklasse DF_PT oder 

Ablauf des Aufbringens von VAS-Daten: 

10 1 . Der Karteninhaber fuhrt eine VAS-Karte in ein Handlertenninal ein. 

2. Das Handlertenninal priift, ob ein VAS-Container vorhanden ist: 

~ S?^Z?!S£ <Air>VAS> (FeWermeldung wenn VAS-Container nicht selektierbar) 

- READ RECORD <SH von EF__ID, 0> (Ausiesen der VAS-Container ID) 

3. Es wird die Echtheit des VAS-Containers gepruft 

SSSSEST 1 5611,51 ^ 865112 MaSlerke y s KGK AUT. kann es eine interne Authentinaerung des WAS- 

- INTERNAL AUTHENTICATE <Zufallszahl, KED von K AUT > 
iTT 1 ( ^ ClCh f "x^o 0 ^ dCn KGK Ain- verftigt) kann indirekt die Echtheit des VAS-Containers 

sScS 6 ™ •^ e, ?!f ln? VAS-APP"^ 0 " A feststellen. Denn eine VAS-Apphkation kann nur an einem 
Semce terminal geladen worden se.n, die beim Ladevonjang die Echtheit des VAS-Containers gepruft hat dZ 
Echthe.tspn.fung der VAS-Appkkation A kann auf den Test des Handlerterminals zuriickgefUhrt weiden ob 

a ^ Da f x Handlerterminal Priift die Antwort und bricht im Fehlerfall (mit Fehlermeldung) ab 

J ^ ^S^f^. VAS-Ap P likation A, authentisiert sich und beschreibt die Elementary Files ' 
die fur die Abwicklung der Trahsaktion notwendig sind: -cicmeniary rues, , 

- SELECT FILE <PLX A > (entfallt, wenn bereits in Schritt 3 durcheeruhrt) 

- G ET CH ALLENGE 6 ' 

- EXTERNAL AUTHENTICATE <K LVASP (Zufallszahl), KID von K L vasp> 

- optional: UPDATE RECORD <SFI von EF_INFO des DF_X Daten> 

- optional: UPDATE RECORD <SFT von EF.INTERNAL des DF_X Daten> 

- optional: UPDATE RECORD <SFI von EF_ VALUE des DF_X, Daten>. 

Als nachstes das Erwerben im Falle der Implementierungsklasse EF_TRANSFER 

.4n S vS e p 7 A ^ A PP Hkationen der Implementierungsklasse EFJTRANSFER (Applikationsklasse Gutschein) muB 
ein VAS-Provider keine propnetare Dateistruktur DF_X fur seine Applikation belegen Die Folge ist, daB ein KarteTn 
haber nicht vor der Nutzung einer VAS-Applikation Gutschein an ein Serviceterminal gehen muB, urn eine VAsTppli- 
kanon zu laden. Er kann dagegen direkt am Handlertenninal sich einen Gutschein oder eine Quitting ^StoT d 
diese an emem anderen lerminal erstatten (durch die Operation Entnehmen) lassen oder den Gutschein bzw die Ouit- 
tung nur einfach vorweisen (durch I^sen). Durch das Aufbringen von VAS-Daten erfolgt somit ein implizites Ladenvon 
VAS-Apphkationender Implementierungsklasse EF_TRANSFER. Fur diese Applikationsklasse existiert die Imnlemen ' 
tierungsklasse ^_TRANSFER, die aus einzelnen Objekten der Art Record besfeht. Ein Eintrag in EF T^Ss't 
d ™ h daS Commando TRANSFER moglich. Das Handlerterminal muB dazu im Besitz eines gfiltigenEnt- 
werter-Schlussels K DEC sein und uber eine PIX A der VAS-Applikation A verfugen. 
Ablauf des Aufbringens von VAS-Daten: 

1 . Der Karteninhaber fuhrt eine VAS-Karte in ein Handlerterminal ein. 

2. Das Handlerterminal pruft, ob ein VAS-Container vorhanden ist: 

- SELECT FILE <AIDvas> (Fehlermeldung wenn VAS-Container nicht selektierbar) 

- READ RECORD <SFI von EF_ID, 0> (Ausiesen der VAS-Container Nummer). 

3. Das Handlerterminal liest die Sequenznummer, die zusatzlich in den MAC aus Schritt 4 eineehf 

- READ RECORD <SH von EF_SEQ, 0> (Ausiesen der Sequenznummer) " 

4. Mit dem Kommando TRANSFER wird in EF_TRANSFER ein Record geschrieben: 

<: t-T 3^ ANSraR<Transaktionsda tum, Veifallsdatum, E^eugerccKle, Daten, PDC A , MAC mit K DFr > 
wa Z% Ha ndlerterminal kann durch Priifung der Antwortnachricht des TRANSFER Kommandos priifen ob der 
• -VAS-Container echt ist (d.'h. in Besitz des gemeinsamen Geheimnisses K DEC ist). Wir verweisen hierzu auch auf 
die vorher beschnebene Antwortnachricht des Kommandos TRANSFER. 

SchlieBlich das Erwerben von VAS-Daten durch Entwerten 

Ein VAS-Provider kann durch einen Entwertevorgang mit dem Kommando TRANSFER im Transferfeld EF TRANS- 
FER ein Anrecht (z. B. Gutschein oder Quittung) erzeugen, das von einem anderen VAS-Provider weiter venvertet wer- 
den kann. Entwertet werden Daten aus dem EF_VALUE bzw. EFJNFO der VAS-Applikation A des entwertenden VAS- 
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Provider. Der Karteninhaber erwirbt in Form eines Objektes in EFJTRANSFER das AnrechL 
Ablauf des Aufbringens von VAS-Daten: 

1. Der Karteninhaber fuhrt eine VAS-Karte in ein Handlerterminal ein. 

2. Das Handlerterminal priift, ob ein VAS-Container vorhanden ist: 

- SELECT FILE <AJD VAS > (Fehlermeldung wenn VAS -Container nicht selektierbar) 

- READ RECORD <SFI von EFJD, 0> (Auslesen der VAS-Container ID). 

3. Das Handlerterminal liest die Sequenznummer, die zusatzlich in den MAC aus Schritt 4 eingeht: 

- READ RECORD <SFI von EF_SEQ, 0> (Auslesen der Sequenznummer). 

4. Das Handlerterminal selektiert die VAS-Applikation A: 

- SELECT FILE <PK A > (Fehlermeldung, falls VAS-Applikation A nicht in den VAS-Container geladen ist); 

5. Das Handlerterminal nutzt das Kommando TRANSFER zum Entwerten der Daten aus dem EF VALUE bzw 
demEFJNFO. 

- TRANSFER <Daten, MAC mit Kq^. 

Die Zusammensetzung der Kommandonachricht von TRANSFER wurde bereits beschrieben. Die Berechti- 
gung zum Entwertevorgang erlangt das Terminal, wenn es eine korrekte Signatur iiber die Daten mit dem 
Schliissel K DEC bilden kann. Diese wird durch den VAS-Container gepruft Bei Erfoig wird vom VAS-Contai- 
ner ein Record in EF_TRANSFER angelegt sowie die Sequenznummer inkrementiert. 

6. Das Handlerterminal kann durch Prufung der Ahtwortnachricht des TRANSFER Kommandos prufen, ob der 
VAS-Container echt ist (d. h. in Besitz des gemeinsamen Geheininisses Kqec ist). 

Und nun noch das Verfahren zum Entwerten von VAS-Daten. Es gibt zwei Arten von Entwertungsvorgangen: 

Zum einen konnen VAS-Daten fur VAS-Applikationen der Implementierungsklasse DF_PT oder DF_AD durch den 
zugehorigen VAS-Provider entwertet werden durch die Operation Entwerten, d. h. Erwerben von VAS-Daten durch Ent- 
werten. Dadurch wird ein Wert verbraucht, wobei ein potentielles Anrecht auf einen weiteren Wert entstehL 

Zum anderen konnen VAS-Daten aus dem EFJTRANSFER einmalig entaommen werden mit dem Erganzungskom- 
mando TAKE. In diesem Fall wird das Anrecht aufgebraucht, die Daten bleiben ftir etwaige weitere Verwendung (z. B. 
riickerstattetes Ticket wird zur Ruckfahrt noch benotigt) im Transferfeid als entnommen gekennzeichnet stehen, bis sie 
bei Bedarf von anderen Objekten uberschrieben werden. 

Ablauf des Entwertens von VAS-Daten durch das Kommando TAKE: 

1. Der Karteninhaber fuhrt eine VAS-Karte in ein Handlerterminal ein. 

2. Das Handlerterminal priift, ob ein VAS-Container vorhanden ist: 

- SELECT FILE <AID VA s> (Fehlermeldung wenn VAS-Container nicht selektierbar) 

- READ RECORD <SFI von EF__ED, 0> (Auslesen der VAS-Container ED). 

3. Zunachst liest das Handlerterminal die zur Verfugung stehenden Objekte aus EF_TRANSFER aus mit dem Spe- . 
zialfall der Operation Ansehen VAS-Applikationen, um zu entscheiden, ob ein gesuchtes Objekt enthalten ist Al- 
ternate kann mit dem Kommando SEEK nach einem Muster gesucht werden. Das Terminal kennt im Erfolgsfall die 
Nummer i des gesuchten Records. 

4. Das Terminal markiert den Record mit Recordnummer i als entfernt, indem es i, eine von ihm berechnete Zu- 
fallszahl, seine PDC und Terminal ID mit dem Kommando TAKE ubermitteit: 

■ - TAKE <i, Zufallszahl, PDC, Terminal ID>. 

Das Handlerterminal nutzt das Kommando TAKE zum Lesen der Daten aus dem EF_TRANSFER bei gleichzeitigem 
Kennzeichnen der Daten als entnommen. Die Ausfuhrung des Kommandos bewirkt zusatzlich die Erzeugung von zwei 
verschiedenen Kryptogrammen C\ und C 2 . 

Das Kryptogramm Q wird durch den VAS-Container mit dem Schliissel K SIG VASC berechnet. Damit kann der Ein- 
reicher des entnommenen, mit C { signierten Objektes sich beim System Operator die Einmaligkeit und Echtheit nach- 
weisen iassen. Die Einmaligkeit und Echtheit der TVansaktion ergibt sich aus dem Kryptogramm des VAS-Providers, von 
dem das Objekt ursprunglich stammt (und die von der Karte gepruft wurde, siehe TRANSFER), und der Fuhrung eines 
Sequenzzahlers iiber die Transaktionen sowie dem Kryptogramm Cj durch die Karte bei der Entnahme. 

Das Kryptogramm C 2 wird durch den VAS-Container mit dem Schliissel K^ EC berechnet, der von dem VAS-Contai- 
ner aus KGK DEC , PIX und Terminal ID abgeleitet wird. Durch Kenntnis des gemeinsamen Geheimnisses kann der 
VAS-Container dem Terminal gegenuber direkt die Echtheit des VAS-Containers beweisen. Da beim TRANSFER Kom- 
mando ebenfalls gepruft wird, daB nur echte Gutscheine bzw. Quittungen in einen echten VAS-Container gespeichert 
werden, kann daraus die Echtheit des entnommenen Objektes gefolgert werden. Da Cj indirekt Uber die Sequenznum- 
mer, das Entnbmmen-Bit und die VAS-Container ID gebildet wird, kann der VAS-Container deni Terminal sogar die Ein- 
maligkeit des entnommenen Objektes nachweisen. 

Die Berechugung zum Entnehmen mit dem Kommando TAKE hat jeder. 

Am Serviceterminal ist ferner die Deaktivierung bzw. Aktivierung eines PaBwort- oder PIN-Schutzes fur das Lesen 
von VAS-Applikationen der Implementierungsklassen DF_PT und DF_AD moglich. AuBerdem kann die PIN des VAS- 
Containers vom Karteninhaber durch der Kenntnis der PIN geandert werden und vom System Operator mittels externer 
Authentifizierung durch Ksq zuriickgesetzt werden. Als PIN oder PaBwort sind auch nicht-numerische Zeichen oder Zei- 
chenketten beliebiger Lange verwendbar. 

Patentanspriiche 

1 . Chipkarte, die zur Durchfuhrung von TVansaktionen dient, bei denen geldwerte Einheiten oder andere nicht-mo- 
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netare Ansprtiche reprasentierende Wertdaten zwischen dem Kaneninhaber und mindestens einem Transaktions 
partner (Serv.ce-Prov.der) iibertragen oder dem Service-Provider zur Verifizierune der An^T,. ™ 
werden, wobei die Chipkarte einen Speicher umfaBt, in dem zur MO^S^^Sl^^^ 
ten abgespecbert werden und die Chipkarte dadurch gekennzeicnnet ist, daB sie folgendS St 
eine E.nnchtung zun, Laden von einer oder mehreren Kartenanwendungen (VAS- Appukau^ennuf die Karte die 
V ° D 1>anSaktionen Zwischen d - KarteninhaLr -d cinZ oder 

2. Chipkarte nach Anspruch 1, bei der die Einrichtung zum Laden foigendes aufweisf 
eine dann abgespeicherte Datenstruktur (DF_VAS, VAS-Container), die aufweisf 

erne TeUstruktur (DF_PT, DF_AD, VAS-Applikation), in die zur Ermoglicbung der Durehfuhrung einer Transak- 
JoTenT Kartemnhaber und einem Service-Provider erfordertiche Daten (VAsSenJ ge"a!j en Ztn 

einen Definitionsdatensatz, der Informatiorien iiber die Art und/oder Struktur der in der Teilstruktur fVAS Annliira 
uon) abgespeicherten Daten enthalt; wobei der Definitionsdatensatz femeTaufweist lgllStnlktUr (VAJ> - A PP hka " 
eme die Datenstruktur (VAS-Container) und/oder die Chipkarte identifizierende Kennung (Container-ID)- und 
mmdesfcns einen System-SchWssel (K so ), der die Integrity des Definitionsdatensatzes undSfde/Siktur 
(VAS-Container) gegen Modifikationen absichert. ^"tiensuustur 

3. Chipkarte nach Anspruch 1 oder 2, dadurch gekennzeichnet, daB sie ferner aufweisf 

e,nen Transfer-Speicherbereich (EF_TOANSFER) zur Aufnahme von bei der Durehfuhrung der Transaktion auszu- 
^uschenden oder vorzuweisenden die geldwerte Einheiten oder nicht monetaren Anspruche reprasen'SendL^a- 

eine Einrichtung zum Schreiben von Daten in den Transferspeicher in Reaktion auf ein Schreibkommando (Kans- 

foi g ^^^ a ,tXtt AnSPrflChe 1 WS 3 ' dadUfCh dafi - weiterhin mindestens eines der 

eine Einrichtung zum Laden von fur die Durehfuhrung von Transaktionen erforderlichen Daten in die Teilstruktur 
unter Verwendung des mindestens einen Systemschliissels; *ciisiruKiur 
eine Einrichuing zum Schreiben von Daten in den Definitionsdatensatz zum Anpassen der Daten des Definitionsda- 
tensatzes an die in die Teilstruktur geladenen Daten; ^enmuonsaa 
eine Einrichtung zum Generieren einer weiteren Teilstruktur, in die zur Durehfuhrung einer Transaktion erforderli- 
che Daten geladen werden konnen, in dem Speicher der Karte; und/oder enoraeru 
eine Einrichtung zur dynamischen Speicherverwaltung auf der Karte. 

5. Chipkarte nach einem der vorheigehenden Anspruche, dadurch gekennzeichnet, daB 

es sich bei den Teilstrukturen (VAS-Applikationen) urn voneinander unabhangige Teilstrukturen handelt die ie- 
weils einem bestimmten Service-Provider zugeordnet sind nanaeit, aie je 

uS^ 

Syl^^ ^ *™ im ^^-nsatz enthaltenen 

6. Chipkarte nach einem der vorhergehenden Anspriiche, dadurch gekennzeichnet, daB der Definitionsdatensatz 
ferner mindestens ernes der folgenden Merkmale aufweisf nsatZ 
mindestens einen Authentifizierungsschliissel (K AUT ) zur Authentifizierung der Berechtigung der Chipkarte gegen- 
uber emem Terminal und/oder zur Authentifizierung der Berechtigung eines Terminals gtgenuber der Chipkarfe 
mindestens einen Sign.erschlussel (K SIG _ VASC ) zum Signieren von aus dem Transferspeicherenmommenen Sn- 

lif Ir^'^'r 1 ^ ZUf B™"*"* von terminal- und applikationsspezifisS 
wertuntvorWeSn 8 Ber<5ChtigUng eineS Schreibvoigangs in den Transferspeicher und/oder einer Ent- 
eine PIN zur Verifikation der Berechtigung eines Transaktionsvorgangs durch den Kaneninhaber 
daB der Systemschlussel (K so ), der Authentizifierungsschlussel (K AUT ), der Signierschlussel (Kc, r VA ^) und der 
Schlusselerzeugungs-SchlOssel (KGK DEC ) kartenindividuelle oder datenstruktur-(DF VAS)-si>eri^^ne SchlUssel 
sind und daB die Teilsuniktur (VAS-Applikation) mindestens eines der folgenden Merkmale aufwe^T 
mindestens einen Wertspeicher (EF_ VALUE) zur Aufiiahme von Wertdaten- 

mindestens einen Intern-Speicher (EF_INTERNAL) zur Aufnahme von internen die Teilstruktur betreffenden Da- 

nundestens einen Infospeicher^EF INFO) zur Aufnahme von nicht intemen die Teilstruktur betreffenden Daten; 
einen Schlusselspeicher (EFKEY) zur Aufnahme mindestens eines Schlussels (K^ K^p), die Schreib- 
und/oder Lesevorgange in den oder aus dem Wertspeicher, und/oder dem Intero-Speicto undffi *Ln Info-Spet 
cher absichem, und daB die Chipkarte femer umfaBt: ^ 
eineEinrichtung zum Schreibenund/oder Lesen von Daten in den oder aus dem Wertspeicher, dem Intern-Speicher 
und dem Infospeicher, und daB die Einrichtung zum Laden umfaBt: 

eine Einrichtung zum Schreiben der Schlussel in den Schlusselspeicher unter Absicherung durch den mindestens ei- 
nen aystemschlussel. 

7. Chipkarte nach einem der vorhergehenden Anspriiche, dadurch gekennzeichnet, daB die Teilstruktur mindestens 
eines der folgenden Merkmale aufweist: 

einen Schlussel (K LVASP ) zum Oberpriiferi der Schreibberechtigung von Daten in die Teilstruktur; 

einen Schlussel (K RVASP ) zum Uberpriifen der Leseberechtigung von Daten aus der Teilstruktur ' 

& Chipkarte nach einem der vorhergehenden Anspruche, dadurch gekennzeichnet, daB die im Schlusselspeicher 

abgespeicherten Schlussel fur die jeweilige Teilstruktur spezifisch sind und daB die mindestens eine Teilstruktur 
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(VAS-Applikation) das Durchfiihren von Transaktionen rnittels mindestens eines der spezifischen Schlussel 
(Klvasp* k rvasp) absichert, der fur die jeweilige Teilstruktur (VAS-Applikation) spezifisch und von den Schlusseln 
anderer Teilstrukturen (VAS-Applikauonen) unabhangig ist 

9. Chipkarte nach einem der vorhergehenden Anspriiche, dadurch gekennzeichnet, daB 

die Karte mehrere der Teilstrukturen (VAS-Applikationen) aufweist, die jeweils zur Durchfuhrung von Transaktio- 
nen zwischen einem bestimmten Service-Provider und dem Karteninhaber dienen, und daB 

das Durchfiihren von Transaktionen das Schreiben und/oderLesen von Daten in das bzw. aus dem Transferfeld und/ 
oder das Schreiben und/oder Lesen von Daten in den bzw. aus dem Wertspeicher umfaBt 

10. Chipkarte nach einem der vorhergehenden Anspriiche, dadurch gekennzeichnet, daB sie femer umfaBt: 

eine Einrichtung zum Durchfiihren von Transaktionen sowohl zwischen einzelnen Teilstrukturen (VAS-Applikatio- 
nen) als auch zwischen einer Teilstruktur und einem Service-Provider: 

11. Chipkarte nach einem der vorhergehenden Anspriiche, dadurch gekennzeichnet, daB 

der System-Schlussel (Ksq) nur dem Systembetreiber (System Operator SO) bekannt ist und ein kartenindividueller 
und/oder Datenstruktur-(VAS-Container)-spezifischer Schlussel ist, und daB 

die weiteren im Definitionsdatensatz enthaltenen Schlussel kartenindividuelle und/oder Datenstruktur-(VAS-Con- 
tainer)-spezifische Schlussel sind. 

12. Chipkarte nach einem der vorhergehenden Anspriiche, dadurch gekennzeichnet, daB der Definitionsdatensatz 
eines oder mehrere der folgenden Merkmale aufweist: 

eine die Datenstruktur spezirizierende Identifikationsnummer (EF_ID) ein Verzeichnis der in der Datenstruktur ent- 
haltenen Teilstrukturen (EF_DER), wobei das Verzeichnis teilstrukturspezifischeldentifikationsnummern von in der 
Datenstruktur (VAS-Container) geiadenen Teilstrukturen (VAS-Applikauonen) enthalt, sowie Informations uber 
den Teil der Datenstruktur (VAS-Container), in dem die Teilstrukturen (VAS-Applikationen) physikalisch gespei- 
chert sind; 

eine Versionsnummer der Datenstruktur (EF_VERSION). 

13. Chipkarte nach einem der vorhergehenden Anspriiche, dadurch gekennzeichnet, daB sie mindestens eines der 
folgenden Merkmale umfaBt: 

eine Einrichtung zur Durchfuhrung eines Entnahmevorgangs (Take), mittels dessen Daten aus dem Transferspei- 
cher entnommen und/oder entwertet werden; 

eine Einrichtung zur Erzeugung eines oder mehrerer Echtheitsmerkmale der Daten bei Entnahme bzw. der Entwer- 
tiing von Daten aus dem Transferspeicher. 

14. Chipkarte nach einem der vorhergehenden Anspriiche, dadurch gekennzeichnet, daB die Chipkarte zur Gene- 
rierung der Echtheitsmerkmale folgendes aufweist: 

einen Signierschiussel K SIGVASC zum Erzeugen einer digitalen Signatur uber den entnommenen Daten; 

eine Einrichtung zur Erzeugung einer die Transaktion kennzeichnenden Transaktionsnummer, die zur Erzeugung 

der digitalen Signatur mitverwendet wird. 

15. Chipkarte nach einem der vorhergehenden Anspriiche, dadurch gekennzeichnet, daB der Signierschiussel 
K sig _vasc ein aus einem P rivaten Key-Generating-Key abgeleiteter privater Schlussel ist und zur Oberpriifung der 
Signatur durch die Serviceprovider offentliche Schlussel herangezogen werden. 

16. Chipkarte nach einem der vorhergehenden Anspriiche, dadurch gekennzeichnet, daB sie mindestens eines der 
folgenden Merkmale umfaBt: 

eine Einrichtung zur Erzeugung von terminal- und teilstrukturspezifischen Schlusseln (Kqec) mittels des Schlussel- 
erzeugungs-Schlussels (KGK DEC ); 

eine Einrichtung zur Verifizierung der RechtmaBigkeit und/oder der Absicherung einer Transaktion unter Verwen- 

dung mindestens eines der folgenden Merkmale: 

des terminal- und teilstrukturspezifischen Schlussels (K^ EC ), 

des mindestens einen Authentifizierungsschliissels (K AUT ), 

des mindestens einen Systemschliissels (K^), 

des mindestens einen teilstrukturspezifischen Schlussels (Kl Vasb k rvasp)» 
des Signierschlussels (K^q vasc)» 
der PIN, 

der Kennung einer Teilstruktur, 
der Kennung eines Terminals. 

17. Chipkarte nach einem der vorhergehenden Anspriiche, dadurch gekennzeichnet, daB die Chipkarte ferner min- 
destens eines der folgenden Merkmale umfaBt: 

eine Einrichtung zum Authentifizieren der Berechtigung und/oder des Terminals mittels des Authentifizierungs- 
schlussels bevor ein Lese- oder Schreibvorgang gestartet wird, 

eine Einrichtung zur Durchfuhrung von Lese- oder Schreibvorgangen, die mit einer digitalen Unterschrift und/oder 
Verschlusselung gesichert sind. 

18. Chipkarte nach einem der vorhergehenden Anspriiche, dadurch gekennzeichnet, daB die Chipkarte ferner min- 
destens eines der folgenden Merkmale umfaBt: 

eine Einrichtung zum Aktivieren und Deaktivieren des PIN-Schutzes, , ■ 

eine Einrichtung zum Abandern der PIN. 

19. Chipkarte nach einem der vorhergehenden Anspriiche, dadurch gekennzeichnet, daB 

die Datenstruktur gemaB einem der vorhergehenden Anspriiche von der Kartenplattform unabhangig ist und die 
Chipkarte femer umfaBt: 

eine Einrichtung zum Ubertragen der Datenstruktur oder von Teilen der Datenstruktur auf eine andere Karte. 

20. Chipkarte, dadurch gekennzeichnet, daB sie folgendes aufweist: 

einen Speicherbereich zum Schreiben oder Lesen von Daten in den oder aus dem Speicherbereich zum Transfer von 
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geldwerten Einheiten und/oder von anderen nicht-monetaren Anspriiche reprasentierenden ^fertdaten zwischen 
identischen oder unterschiedlichen Service-Providem. 

Vn J en ^ n21 ZU f Verwendun S ™ l einef Chipkarte gemaB einem der Anspriiche 1 bis 20, dadurch gekennzeichnel, 
daB das Terminal umfafit: 

eine Einrichtung zum Identifizieren der Datenstruktur (VAS-Container) der Chipkarte sowie zur Identification der 

die Datenstruktur identifizierenden Kennung (Container-ID); 

und daB es ferner mindestens eines der folgenden Merkrnale umfaBt: 

eine Einrichtung zum Lesen von Daten aus mindestens einer der Teilstrukturen und/oder dem Definitionsdatensatz 
und/oder dem Transferspeicher der Karte; 

eine Einrichtung zum Schreiben von Daten in den Transferspeicher der Karte; 

eine Einrichtung zurn Laden der zur Durchfuhrung von Transaktionen erforderlichen Daten in mindestens eine der 
Teilstrukturen (VAS-Appiikationen) der Karte. 

22^ Terminal nach Anspruch 21, dadurch gekennzeichnel, daB es ferner mindestens eines der folgenden Merkrnale 
aufweist: 

eine Einrichtung zur Durchfuhrung von Transaktionen zwischen einem Service-Provider und dem Karteninhaber 
wobei das Durchfiihren einer Transaktion mindestens einen der folgenden Schritte umfaBt: 
das Schreiben von Daten in den Wertspeicher, 
das Schreiben von Daten in den Transferspeicher, 

das Entnehmen und/oder Entwerten von Daten aus dem Transferspeicher, 

das Lesen von Daten aus der Teilstruktur, 

das Lesen von Daten aus dem Transferspeicher. 

23. Terminal nach einem der Anspriiche 21 oder 22, dadurch gekennzeichnel, daB es ferner umfaBf 

eine Einrichtung zur Verifizierung der RechtmaBigkeit und/oder der Absicherung einer Transaktion unter Verwen- 

dung mindestens eines der folgenden Merkrnale: 

eines terminal- und teilstrukturspezifischen Schlussels (Ko EC )> 

des mindestens einen kartenindividuellen oder datenstruktur-(DF^VAS>spezifischen Authentifizierungsschliissels 

des mindestens einen kartenindividuellen oder datenstruktur-(DF_VAS)-spezifischen Systemschlussels (Kc n ) 
des mindestens einen teilstrukturspezifischen Schlussels (K^^p K RVASP ), 

des kartenindividuellen oder datenstruktur-(DF_VAS)-spezifischen Signierschlussels (Kc Tr V Asr) 
der kartenindividuellen oder datenstruktur-(DF_VAS>spezifischen PIN, ~ ' 

der applikationsspezifischen Kennung einer Teilstruktur, 
der terrninalspezifischen Kennung eines Terminals. 

24. Terminal nach einem der Anspriiche 219 bis 23, dadurch gekennzeichnel, daB die Einrichtung zum Schreiben 
von Daten in den Transferspeicher aufweist: 

eine Einrichtung zum Verschlusseln von Daten unter Verwendung eines terminal- und teilstrukturspezifischen 
Schlussels (Kdec) zum Nachweis der Schreibberechtigung. 

25. Terminal nach einem der Anspriiche 21 bis 24, dadurch gekennzeichnel, daB es ferner aufweist: 

eine Einrichtung zum Durchfiihren eines Entnahmevorgahgs von Daten aus dem Transferspeicher, mittels dessen 
Daten aus dem Transferspeicher entnommen und/oder entwertet werden. 

26. Terminal nach einem der Anspriiche 21 bis 25, dadurch gekennzeichnel, daB es ferner mindestens eines der fol- 
genden Merkrnale aufweist: 

eine Einrichtung zum Kennzeichnen von Daten des Transferspeichers als entnommen, 
eine Einrichtung zum Kennzeichnen von Daten des Transferspeichers als verfallen. 

27. Terminal nach einem der Anspriiche 21 bis 26, dadurch gekennzeichnel, daB die Einrichtung zum Durchfiihren 
von Transaktionen mindestens eines der folgenden Merkrnale aufweist: 

eine Einrichtung zum Andern von Wertdaten in der Teilstruktur; 

eine Einrichtung zum Durchfiihren von Transaktionen zwischen verschiedenen Service-Providern (Interservices) 
auf Kosten bzw. zum Nutzen des Karteninhabers. 

28. Terminal nach einem der Anspriiche 21 bis 27, dadurch gekennzeichnet, daB es ferner aufweist: 

eine Einrichtung zum Authentifizieren der Berechtigung des Terminals gegenuber der Karte und/oder der Karte ge- 
genuber dem Terminal unter Verwendung mindestens eines Authentifizierungsschlussels; 
eine Einrichtung zum Absichern einer Transaktion durch den Karteninhaber mittels einer PIN; 
eine Einrichtung zum Aktivieren und Deaktivieren des PIN-Schutzes. 

29. Terminal nach einem der Anspriiche 21 bis 28, dadurch gekennzeichnel, daB es femer mindestens eines der fol- 
genden Merkrnale aufweist: 

eine Einrichtung zum Obertragen einer terrninalspezifischen Kennung an die Karte; 
eine Einrichtung zum Obertragen einer die Teilstruktur spezifizierenden Kennung an die Karte; 
eine Einrichtung zum Authentifizieren der Berechtigung unter Verwendung eines terminal- und teilstrukturspezifi- 
schen Schlussels sowie der terminal- und teilstrukturspezifischen Kennung, 

eine Einrichtung zur Durchfuhrung von Lese- oder Schreibvorgangen, die mit einer digitalen Unterschrift und/oder 
Verschlusselung gesichert sind. 

30. Terminal nach einem der Anspriiche 21 bis 29, dadurch gekennzeichnel, daB es femer mindestens eines der fol- 
genden Merkrnale aufweist: 

eine Einrichtung zum Selektieren einer Teilstruktur (VAS-Applikation); 

eine Einrichtung zum Ansehen einer Teilstruktur auf dem Terminal; 

eine Einrichtung zum Ansehen der Daten einer Teilstruktur auf dem Terminal; 

eine Einrichtung zum Laden einer Teilstruktur (VAS-Applikation) auf die Karte; 
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eine Einrichtung zum Laden einer Kennung einer geladenen Teilstruktur (VAS-Applikauon) auf die Karte, 

eine Einrichtung zum Loschen einer Teilstruktur von der Karte; 

eine Einrichtung zum Substituieren einer Teilstruktur durch eine andere Teilstruktur, 

eine Einrichtung zum Ubertragen einer Teilstruktur auf eine andere Karte; 

eine Einrichtung zum Interprederen einer Teilstruktur bezuglich ihrer Funktion und ihres zugeordneten Service- 5 
Providers sowie zurn Lesen und Ansehen von in ihr gespeicherten Informationen. 

31. Verfahren zum Durchfuhren von Transaktionen zwischen einem Karteninhaber und mindestens einem Service- 
Provider unter Verwendung einer Chipkarte sowie eines Terminals, wobei das Verfahren einen der folgenden 
Schritte umfaBt: 

Vorsehen einer auf der Chipkarte abgespeicherten Datenstruktur, in die zur Ermoghchung der Durchfiihrung der 10 
Transaktion zwischen dem Karteninhaber und einem Service-Provider erforderliche Daten (VAS-Daten) geladen 
werden konnen, sowie Schreiben oder Lesen von Daten in die/aus der Datenstruktur (VAS-Applikation); 
Vorsehen eines Transfer-Speicherbereichs (EF_TRANSEER) zur Aufhahme von bei der Durchffinrung der Trans- 
aktion auszutauschenden oder vorzuweisenden die Geidwerteeinheiten oder nicht-monetaren Anspriiche reprasen- 
tierenden Daten, sowie Schreiben von Daten in den Transferspeicher oder Lesen von Daten aus dem Transferspei- 15 
cher. 

32. Verfahren nach Anspruch 31, dadurch gekennzeichnet, daB das- Verfahren mindestens einen der folgenden 
Schritte umfaBt: 

Verwendung einer Chipkarte gemaB einem der Anspriiche 1 bis 20; 

Verwendung eines Terminals gemaB einem der Anspriiche 21 bis 30; 20 
Schreiben oder Lesen von Daten in den/aus dem Wertspeicher oder Intem-Speicher oder Info-Speicher von minde- 
stens einer der Teilstrukturen (VAS-Applikationen). 

33. Verfahren nach Anspruch 31 oder 32, dadurch gekennzeichnet, daB es ferner mindestens einen der folgenden 
Schritte umfaBt: 

Authentifizieren der Berechtigung des Terminals und/oder der Chipkarte unter Verwendung mindestens eines 25 
Schlussels; 

Absichern der Transaktion durch Verwendung einer digitalen Unterschrift und/oder Verschlusselung durch Verwen- 
dung mindestens eines Schlussels. 

34. Verfahren zum Laden von Daten auf eine Chipkarte unter Verwendung eines Terminals, dadurch gekennzeich- 
net, daB das Verfahren mindestens einen der folgenden Schritte umfaBt: 30 
Laden von Daten in eine Teilstruktur (VAS-Applikation) der Karte; 

Schreiben von Daten in den Definitionsdatensatz der Karte. 

35. Verfahren zum Laden von Daten nach Anspruch 34, welches mindestens einen der folgenden Schritte umfaBt: 
Verwendung einer Chipkarte gemaB einem der Anspriiche 1 bis 20; 

Verwendung eines Terminals gemaB einem der Anspriiche 21 bis 30. 35 

36. System zur Durchfiihrung von Transaktionen, gekennzeichnet durch: 
eine Chipkarte gemaB einem der Anspriiche 1 bis 20 und 

ein Terminal gemaB einem der Anspriiche 21 bis 30. 

Hierzu 8 Seite(n) Zeichnungeri 40 
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